Status Update
Comments
cs...@google.com <cs...@google.com> #2
Android 5.0, 5.1: it shows context menu at top of screen, not as popup. See screenshots.
Android framework doesn't support floating toolbar before 23. So this is intended behavior.
The crash information suggests that this is an error from Snapshot. chuckj@ can you please take a look? I don't know what exactly caused the readError
in Snapshot, any suggestions? Thanks a lot!
ap...@google.com <ap...@google.com> #3
This looks like another instance of 193006595 which I am looking at now.
ch...@google.com <ch...@google.com>
ap...@google.com <ap...@google.com> #4
Branch: androidx-main
commit beeb84e7be604088ad40e080a8d0adb1bacbf695
Author: Chuck Jazdzewski <chuckj@google.com>
Date: Thu Jul 08 10:04:28 2021
Remove updating the transparent snapshot
A transparent snapshot is create for the block exeucted by
`Snapshot.observe()` which registers read and write observers
but without creating a snapshot. The code to advance the
global snapshot, however, created a new transparent snapshot in
an attempt to update it to the new global snapshot it just
created. This is not necessary, however, as the transparent
snapshot will retrieve the current global snapshot from
`currentGlobalSnapshot` instead of `previousSnapshot` if
`previousSnapshot` is `null`. With the previous code, if the
global snapshot is advanced by applying a new snapshot the
"updated" transparent snapshot will be left referring to an
older snapshot instead of the most recent global snapshot.
Any snapshot object created in the newly applied snapshot
will throw an exception when it is accessed, as reported in
the bugs. The solution is to remove the apparent vetiagal code.
Test: ./gradlew :compose:r:r:tDUT
Fixes:
Change-Id: I2c0d0b8f57bf70e5a98ea36ed141d97142a5e53e
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/snapshots/Snapshot.kt
M compose/runtime/runtime/src/test/kotlin/androidx/compose/runtime/snapshots/SnapshotTests.kt
na...@google.com <na...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.compiler:compiler-hosted:1.5.0
ae...@google.com <ae...@google.com> #6
I temporarily removed the first performance optimization aosp/2636327 in aosp/2676415 because it caused a bug with subcomposition
ap...@google.com <ap...@google.com> #7
Branch: androidx-main
commit 3118e88c6485cb8003b30e6bc09ee302ca4557ce
Author: Chuck Jazdzewski <chuckj@google.com>
Date: Thu Jul 27 16:30:42 2023
Fix and re-enable providers optimization
Disabled the single provider optimization because it could cause
the composition local scope to be incorrect.
It was incorrect when the provider cache was invalidated by a
provider closing just before the composer scope was read again
which causes it to re-lookup the current provider scope. The
`startProvider` call neglected to set the `writerHasAProvider` that
would cause the writer to be inspected for a provider not just the
reader (as the provider is being added during the composition).
The fix is to add this flag at the same location it is in
`startProviders()`.
Bug: 292224893
Fixes: 288169379
Test: ./gradlew :compose:r:r:tDUT
Change-Id: I883c3ba691e41821944a3020eaa1089130cf11a3
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/Composer.kt
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/CompositionLocal.kt
M compose/runtime/runtime/src/nonEmulatorCommonTest/kotlin/androidx/compose/runtime/CompositionLocalTests.kt
na...@google.com <na...@google.com> #8
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.runtime:runtime:1.6.0-alpha03
androidx.compose.runtime:runtime-android:1.6.0-alpha03
androidx.core:core-testing:1.12.0-rc01
Description
Summary
The current API for providing composition locals is very allocation heavy and requires several groups. This can be improved in several ways,
The current API will allocated an array to store the providers and a mall object to for each "provides" parameter. It will then create a persistent map of the provided values and then union of the existing map and this map as the persistent scope.
Some composable function just provide one provides which makes these allocation particularly heavey weight. Also, constructing the union persisent map can be expensive.
Proposals
1. Special case single provider
The single provider can be special cased to avoid the creating of the array, the
ProvidesValue
instance and the persistent map.This would require new API that takes the composition local definition and the value (as well as a corresponding lint with a quick-fix to migrate code to the new API).
2. Allow building the map directly outside composition.
Instead of building the map in composition, the local map (for large maps) can be constructed as helper or outside composition entirely. This is specifically helpful when the map is conditionally built the current API requires paying the local provider overhead multiple times for shared or conditional providers.
This will require a new API that allows providing a composition local map directly.
3. Faster persistent maps
The persistent map is a general map that handles many cases well but it doesn't handle small changes well (such as adding a single value). We could provide a wrapper around the persistent map that will handles the special cases found in the Compose library better such as a singleton wrapper for cases, such when a single value is provided.
This doesn't require any API changes.