Status Update
No update yet.
Comments
jo...@google.com
ga...@gmail.com
After some brief poking around:
Relevant code in LayoutNode:
Ends up here:
If accessibility is off, looks like changing progress semantics a no op which would be a big improvement to performance.
Otherwise semantics does a remeasure / relayout, and walks the full semantics tree. This would likely have no immediate benefit if accessibility is turned on.
se...@google.com
se...@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.
ha...@gmail.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.
se...@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.
ha...@gmail.com
+1 to Leland's approach. That is aligned with my thinking here.
se...@google.com
se...@google.com
ke...@google.com
ap...@google.com
I'm annoyed I missed this option, really nice and clean.
jo...@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
Description
Compose 1.4.0-alpha04 introduced a max width constraint on
ModalBottomSheetLayout. However, theFor larger screens, bottom sheets have a default max-width to prevent undesired layouts and awkward spacing. However, this can be overridden if needed.
I have designs that expect, and will take advantage of, the entire screen width in a bottom sheet, and would like to have this behaviour without creating my own implementation.
As noted in the
I'm not sure what the intended behaviour here is as there seems to be a difference between Material 2 and 3. Since
ModalBottomSheetLayoutis incompose.materialand notcompose.material3I assume it isn't based on Material 3. If that is the case, is there a plan to add a corresponding component incompose.material3with a modal bottom sheet that can override the max width constraint?