Status Update
Comments
jb...@google.com <jb...@google.com> #2
frameworks/support/compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/Chip.kt
jb...@google.com <jb...@google.com> #3
Branch: androidx-main
commit 50a35b0cda0a79d7cfb0d5db8a00462b49f02b3e
Author: Connie Shi <connieshi@google.com>
Date: Mon Oct 30 12:59:10 2023
Make the constructor for `ChipElevation` and `SelectableChipElevation` public.
Bug: 308432421, 307583745
Test: Ran existing tests.
Relnote: "Make the constructor for `ChipElevation` and `SelectableChipElevation` public."
Change-Id: Ie0c48d7eec6b96d0276d434ed91ad94e53ad6a6c
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/Chip.kt
co...@google.com <co...@google.com>
ys...@google.com <ys...@google.com> #4
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 <ae...@google.com> #5
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 <le...@google.com> #6
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 <jb...@google.com> #7
+1 to Leland's approach. That is aligned with my thinking here.
ys...@google.com <ys...@google.com> #8
I'm annoyed I missed this option, really nice and clean.
ma...@google.com <ma...@google.com>
ap...@google.com <ap...@google.com> #9
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 <jb...@google.com> #10
Thank you Max!
pr...@google.com <pr...@google.com> #11
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.2.0-alpha10
androidx.compose.material3:material3-android:1.2.0-alpha10
androidx.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.