Status Update
Comments
se...@google.com <se...@google.com>
jw...@gmail.com <jw...@gmail.com> #3
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.
jw...@gmail.com <jw...@gmail.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.
jw...@gmail.com <jw...@gmail.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.
ja...@gopuff.com <ja...@gopuff.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.
ge...@gmail.com <ge...@gmail.com> #7
+1 to Leland's approach. That is aligned with my thinking here.
co...@google.com <co...@google.com> #8
I'm annoyed I missed this option, really nice and clean.
ja...@gopuff.com <ja...@gopuff.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
ma...@google.com <ma...@google.com>
ja...@gopuff.com <ja...@gopuff.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
ma...@google.com <ma...@google.com> #12
ja...@gopuff.com <ja...@gopuff.com> #13
What Compose [BOM] version can we expect the fix for M2 and M3 in?
ap...@google.com <ap...@google.com> #14
Branch: androidx-main
commit b3e6ebe4229e10fa0711277b139316d3e6c0e0ed
Author: Max Alfonso-Ying <maxying@google.com>
Date: Tue Feb 27 16:14:27 2024
Revert "Focus EDM popup when opened when TalkBack is on"
This revert is for M2 only. M3 has a fix-forward in
aosp/2977881.
This reverts commit 6d0af84f14057929daa80a4fd8325c258295992c.
Reason for revert: Accidentally changed focusability of popup
when TalkBack is off.
Bug:
Test: manually with TalkBack both on and off
Change-Id: I03e9fb02e232b9626a37db90b1a3ccffb73c2736
M compose/material/material/src/androidMain/kotlin/androidx/compose/material/internal/ExposedDropdownMenuPopup.android.kt
ma...@google.com <ma...@google.com> #15
androidx.compose.material:material:1.6.3
and androidx.compose.material3:material3:1.2.1
. A new BOM should be available when this happens.
ja...@gopuff.com <ja...@gopuff.com> #16
Thank you! That sounds awesome.
ap...@google.com <ap...@google.com> #17
Branch: androidx-main
commit 3170fdd82ffa9cd96883e9446d8f2d0e8b118787
Author: Max Alfonso-Ying <maxying@google.com>
Date: Thu Feb 22 18:48:18 2024
Add customization parameters to EDM
Most notably, EDM focusability is now customizable.
Also cleaned up some doc wording.
Test: Updated unit tests
Bug:
Fixes:
Relnote: "ExposedDropdownMenu is now implemented using Popup. The
behavior should be the same except focusable menus with editible
text fields may be dismissed when typing on the keyboard."
Relnote: "Added parameters to customize ExposedDropdownMenu.
In particular, menus now have a `focusable` parameter
(default `true`) that should be set to `false` when working
with editable text fields."
Change-Id: I4184c21ee9f6ac3a5dcffceb1014b3e4b26eccb9
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/ExposedDropdownMenuSamples.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/ExposedDropdownMenuTest.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/ExposedDropdownMenu.android.kt
na...@google.com <na...@google.com> #18
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material:material:1.6.3
androidx.compose.material:material-android:1.6.3
androidx.compose.material:material-desktop:1.6.3
androidx.compose.material:material:1.7.0-alpha04
androidx.compose.material:material-android:1.7.0-alpha04
androidx.compose.material:material-desktop:1.7.0-alpha04
androidx.compose.material3:material3:1.2.1
androidx.compose.material3:material3-android:1.2.1
androidx.compose.material3:material3-desktop:1.2.1
androidx.compose.material3:material3:1.3.0-alpha02
androidx.compose.material3:material3-android:1.3.0-alpha02
androidx.compose.material3:material3-desktop:1.3.0-alpha02
pr...@google.com <pr...@google.com> #19
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.3.0-alpha03
androidx.compose.material3:material3-android:1.3.0-alpha03
androidx.compose.material3:material3-desktop:1.3.0-alpha03
Description
Versions
Kotlin Compiler extension: 1.5.8
Jetpack Compose bom version: 2024.01.00
androidx.compose.material3:material3 version: 1.2.0-alpha06 - 1.2.0-rc01
Jetpack Compose component used: ExposedDropdownMenuBox / ExposedDropdownMenu / DropdownMenuItem
Android Studio Build: Android Studio Hedgehog | 2023.1.1 Patch 2
Kotlin version: 1.9.22
Issue
We use appium to run our instrumented tests on browserstack, which uses the accessibility functionality to find elements on the screen. Up until alpha05 this worked fine for our dropdown text field (also inside the appium layout inspector, this allowed us to see and select the specific dropdown items). To achieve this, we set the semantics modifier on the DropdownMenuItems.
After material3:1.2.0-alpha06 this changed, and the DropDownMenu was no longer selectable through appium. Seen that the changelog of alpha06 specifically mentions the DropDownMenu, maybe something was accidentally removed here?
If there was a change in how we should approach a drop-down text field after alpha06, I'd like to be referred to that documentation. :)
Note that there is no issue in normal user-use of the composable, just the automated ui tests, that rely on the accessibility functionality.
Steps to Reproduce or Code Sample to Reproduce:
Stack trace (if applicable):
Not available.