Status Update
No update yet.
Comments
cl...@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.
an...@gmail.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.
sa...@persgroep.net
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
ap...@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.
se...@google.com
na...@google.com
+1 to Leland's approach. That is aligned with my thinking here.
Description
Jetpack Compose version: 1.2.0-alpha06 Jetpack Compose component used: ScrollableTabRow Android Studio Build: Android Studio Bumblebee | 2021.1.1 Patch 2 Build #AI-211.7628.21.2111.8193401 Kotlin version: 1.6.10
Our design system requires custom tab padding between tabs and for the tab minimum width to be customized. Within the
ScrollableTabRow, every tab has a constraint around a hard-coded minimum tab width, which disallows us from using the standardScrollableTabRowcomposable.See the line:
I'm proposing that
minTabWidtheither be provided as an optional parameter on theScrollableTabRowcomposable with an ability to not have a constraint set or that it hooks into the modifier.I'm also proposing that we have a separate, new
tabPaddingparameter so that we can customize the left and right padding of the view that is composed for the Tab. Currently, this is being created by theScrollableTabRowfor us and there is no way for us to customize it. It would be beneficial to allow developers to customize this.