Status Update
Comments
mo...@google.com <mo...@google.com> #2
Hi. Thanks for reporting this. Fixed in alpha-04
pa...@google.com <pa...@google.com> #3
Branch: androidx-main
commit e782987543a9f8ccd485e970ddc74564b24378db
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Mon Jan 02 15:27:40 2023
fix: tab row crashes when only 1 tab is added
Bug:
Test: Added unit test
Change-Id: I6381dbac304fc1d69d3708c6655f8b595668e93f
M tv/tv-material/src/androidTest/java/androidx/tv/material/TabRowTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/TabRow.kt
jl...@google.com <jl...@google.com> #4
jl...@google.com <jl...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.tv:tv-material:1.0.0-alpha04
nj...@google.com <nj...@google.com> #6
As far as the benchmark regressions are concerned, I believe this particular benchmark incurs more overhead in the worse case scenario that might not map directly to re-world performance. Because we are drawing text into a separate layer first, we are paying an additional (usually one time cost) of this caching work. However, we would see a benefit of subsequent draws of text being much faster as long as the text content doesn't change.
In
androidx.ui.benchmark.test.TextInColumnBenchmark_first_draw_100_
we see a regression because this test repeatedly tears down and rebuilds the compose UI. This requires fully reconstructing the entire text composable as well as the overhead associated with creating the layer which we did not have before.
Similarly in androidx.ui.benchmark.test.TextInColumnBenchmark_toggleRectangleColor_draw_100_
it looks like each time the toggle is changed, we are modifying the font size which again would require recreating the layer before drawing again negatively impacting this particular benchmark's performance.
Alternatively, this would explain the performance improvements that we are seeing in the Checkbox/RadioGroup test cases. In these cases we are toggling state that ends up modifying the Checkbox or RadioGroup but not the Text composable across recompositions. We are seeing the performance gain of drawing the content from the separate layer rather than having to draw the text directly to the screen.
Generally, this seems like a tradeoff between startup benchmarks and iterative ones. If we invest in solutions to cache and re-use results across invocations, we will see benchmark improvements across subsequent draw calls, however, we will see performance regressions in startup performance. I think it is great we are tracking the differences across all benchmarks but in this particular scenario it might be more appropriate to see how this particular change behaves in more real world scenarios. From a personal perspective, I think this change is an overall benefit as we would see better performance in animation like scenarios especially when UI elements around the Text are changing which would cause re-draws for the AndroidComposeView or other layer the composables might be animating within.
mo...@google.com <mo...@google.com> #7
We might be able to improve the performance of this by reusing layers.
pa...@google.com <pa...@google.com> #8
I agree with you Nader that we definitely care more about "frequent" updates rather than one time cases (unless we start considering cases like recycler view). But I just file a bug for any performance change and let the owners to decide on the strategy as I don't have enough context to make the call.
mo...@google.com <mo...@google.com> #9
I tried caching layers (per AndroidComposeView) and am not able to significantly affect the performance. I think the performance problems may be due to reflection calls in the View implementation. I will experiment with this.
ap...@google.com <ap...@google.com> #10
Branch: androidx-master-dev
commit 47330e9a6400a0ea10e6ef007661ae14523fa529
Author: George Mount <mount@google.com>
Date: Tue Sep 01 11:00:24 2020
Move layer creation to attach point.
Layers should not be created during layout and draw, but instead
in less time-critical part of the operation. This moves layer
creation to the commit time, when the modifier is attached.
Relnote: "Removed onInvalidate() from Owner -- OwnedLayer
handles invalidation."
Fixes: 162061312
Test: ui connectedCheck
Test: TextInColumnBenchmark#layout
Change-Id: Ica72b49b10b5f2bd25845cb6c9fc45f085b679e7
M compose/ui/ui/api/current.txt
M compose/ui/ui/api/public_plus_experimental_current.txt
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/input/pointer/PointerInputEventProcessorTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidViewsHandler.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/DelegatingLayoutNodeWrapper.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/LayerWrapper.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/LayoutNode.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/LayoutNodeWrapper.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/Owner.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopOwner.kt
M compose/ui/ui/src/test/kotlin/androidx/compose/ui/node/LayoutNodeTest.kt
ap...@google.com <ap...@google.com> #11
Branch: androidx-master-dev
commit b727b3532cc88187ff73ee6d14ecf9d884bb1b04
Author: George Mount <mount@google.com>
Date: Fri Aug 28 08:57:00 2020
Support RenderNode on M-O devices.
Bug: 162061312
To avoid reflection, a new stub library was created to
support RenderNode on older devices. This should also improve
allocation performance as RenderNodes should be much smaller
and easier to allocate than Views.
This does not currently work on P devices because ART
does not allow access to APIs in the unsupported list on P.
TextInColumnBenchmark#first_draw is around 30% faster in
my local tests.
This CL will make benchmark performance slower on M-O devices,
but it is more representative of actual performance. It turns
out that PictureRecordingCanvas has faster access than
DisplayListCanvas and was giving artificially fast results
on devices that don't support hardware accelerated canvas.
Test: demo on API 23, 26, 29
Test: TextInColumnBenchmark#first_draw
Test: New test for fallback for M RenderNode to View
Change-Id: Ia10caea550f328368c4f0f4384267058d1dbc541
M compose/test-utils/build.gradle
M compose/test-utils/src/androidMain/kotlin/androidx/compose/testutils/AndroidComposeTestCaseRunner.kt
A compose/ui/ui-android-stubs/build.gradle
A compose/ui/ui-android-stubs/src/main/AndroidManifest.xml
A compose/ui/ui-android-stubs/src/main/java/android/view/DisplayListCanvas.java
A compose/ui/ui-android-stubs/src/main/java/android/view/RenderNode.java
M compose/ui/ui/build.gradle
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/AndroidLayoutDrawTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.kt
A compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/DeviceRenderNode.kt
A compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeApi23.kt
A compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeApi29.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeLayer.kt
M ui/settings.gradle
Description
Alert on dashboard:https://androidx-perf.skia.org/t/?begin=1595016806&end=1595016807&subset=all
CLs in build:https://android-master-ingest.skia.org/r/6689866?branch=aosp-androidx-master-dev
Suspected CL: aosp/1362976
Improvements:
Regressions:
Layout regression: