Status Update
No update yet.
Comments
jb...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <
Link:
Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling
Expand for full commit details
Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling
These APIs allow overscroll to have events dispatched to it by one component, and rendered in a separate component.
Fixes: b/266550551
Fixes: b/204650733
Fixes: b/255554340
Fixes: b/229537244
Test: OverscrollTest
Relnote: "Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling APIs - these APIs create a wrapped instance of the provided overscroll effect that doesn't draw / handle events respectively, which allows for rendering overscroll in a separate component from the component that is dispatching events. For example, disabling drawing the overscroll inside a lazy list, and then drawing the overscroll separately on top / elsewhere."
Change-Id: Idbb3d91546b49c1987a041f959bce4b2b09a9f61
Files:
- M
compose/foundation/foundation/api/current.txt - M
compose/foundation/foundation/api/restricted_current.txt - M
compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/OverscrollDemo.kt - M
compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/OverscrollSample.kt - M
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/OverscrollTest.kt - M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/Overscroll.kt
Hash: f64e25b7a473c757d080521e7dd97b3f6670f60d
Date: Fri Nov 01 18:43:56 2024
jb...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.8.0-alpha06androidx.compose.foundation:foundation-android:1.8.0-alpha06androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha06androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha06
co...@google.com
ys...@google.com
Would this suggestion also avoid recomposing, which seems like it would still be a problem even if it's a no-op in the guts of semantic node code.
ae...@google.com
Indeed we could change the progressSemantics API to be lambda-based like ScrollAxisRange, but I'm reluctant to add to our API for this. A number of properties are likely getting updated at high frequency by some application or other. Each one will add API clutter and add to the number of decisions developers have to make to optimize performance.
The semantics block is already a lambda, so we have been talking about being able to make it run separately from composition when one of its inputs changes, much like layout. Ralston is already starting to work on a performance-oriented rearchitecture to semantics and we can discuss how this might fit into that plan.
le...@google.com
The semantics block is already executed outside of composition. That change was made and landed in 1.5.
We honestly don't have to create a new API for this. Modifier.progressSemantics is just a convenience API around the already public progressBarRangeInfo API. Material3 could easily just use a plain Modifier.semantics call with the value resolved inside the lambda and this semantics property set and it would avoid composition and fix this issue.
jb...@google.com
+1 to Leland's approach. That is aligned with my thinking here.
ys...@google.com
I'm annoyed I missed this option, really nice and clean.
ma...@google.com
ap...@google.com
Branch: androidx-main
commit 9b4bfdee9439d9bb9145e61137427221e46511d9
Author: Max Alfonso-Ying <maxying@google.com>
Date: Tue Sep 26 21:34:49 2023
Improve progress indicator perf
- Use lambda for progress to defer all work to draw phase
instead of recomposing
- Pre-allocate IncreaseSemanticsBounds modifier instead
of recreating it.
Fixes:
Test: ProgressIndicatorTest and ProgressIndicatorBenchmark.
Local device shows improvements of 80% for `changeProgress`.
Relnote: "Added new overloads of `LinearProgressIndicator` and
`CircularProgressIndicator` that take `progress` as a lambda.
These should be more performant than the previous versions."
Change-Id: I824e6ba4d57e713ad47f97f25a41c330b3439eb0
M compose/material3/benchmark/src/androidTest/java/androidx/compose/material3/benchmark/ProgressIndicatorBenchmark.kt
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/samples/src/main/java/androidx/compose/material3/samples/ProgressIndicatorSamples.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/ProgressIndicatorScreenshotTest.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/ProgressIndicatorTest.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/ProgressIndicator.kt
jb...@google.com
Thank you Max!
pr...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.2.0-alpha10androidx.compose.material3:material3-android:1.2.0-alpha10androidx.compose.material3:material3-desktop:1.2.0-alpha10
Description
When there are animated updates to progress for UIs like "Instagram Stories" or "Google Photos" which are frequent this becomes a problem.
Ideally, these APIs should have a parameter for `progressProvider: () -> Float` instead of just `progress: Float`.
This actively impacts some card types on Play's Apps and Games Home pages.