IssueTracker

Relevant APIs: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/ProgressIndicator.kt;l=318

After some brief poking around:

Relevant code in LayoutNode: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/LayoutNode.kt;l=421?q=semantics%20f:layoutnode&ss=androidx%2Fplatform%2Fframeworks%2Fsupport:compose%2F

Ends up here: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeViewAccessibilityDelegateCompat.android.kt;l=2152?q=onSemanticsChange%20lang:kt&ss=androidx%2Fplatform%2Fframeworks%2Fsupport:compose%2F

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.

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.

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.