Fixed
Status Update
No update yet.
Comments
je...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit a330c0d3bcdd41326f37968a60e6084ad4a2e32c
Author: Chet Haase <chet@google.com>
Date: Wed Jul 05 07:26:46 2023
Convert APIs using PointF to use Float instead
PointF is a convenient mechanism for passing around x.y values
representing 2D points. But there are downsides, including:
- Converting to PointF: You may not have the data in PointF form
to begin with, so using an API which takes PointF requires converting
the data to that form (including allocating a PointF object every time)
- Mutability: Point structures can be mutated internally, causing
unpredictability in what that mutation means. Should the library
react to those changes? Ignore them? Do defensive copies (requiring
even more allocations)? Using primitive types like Float make the
behavior more obvious (by making the data inherently immutable).
- Allocations: Whenever we use object types, there are necessarily
allocations on the Java heap for them. This puts pressure on the GC
at both allocation and collection time. Given the amount of points
being passed around (especially at morph creation time, when curves
are being split and created), this causes a lot of PointF objects to
be allocated (even temporarily). Using Float avoids that problem.
Also fixed bug with unclosed paths causing discontinuity at the
start/end point.
Bug: 276466399
Bug: 290254314
Test: integration and unit tests pass
Relnote: PointF parameters changed to Float pairs
Change-Id: Id4705d27c7be31b26ade8186b99fffe2e2f8450e
M graphics/graphics-shapes/api/current.txt
M graphics/graphics-shapes/api/restricted_current.txt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicShapeTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonMeasureTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/RoundedPolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/ShapesTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/TestUtils.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Cubic.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/CubicShape.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FeatureMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FloatMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Morph.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/PolygonMeasure.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/RoundedPolygon.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Shapes.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Utils.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/DebugDraw.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/ShapeEditor.kt
M graphics/integration-tests/testapp/src/main/java/androidx/graphics/shapes/test/MaterialShapes.kt
https://android-review.googlesource.com/2649119
Branch: androidx-main
commit a330c0d3bcdd41326f37968a60e6084ad4a2e32c
Author: Chet Haase <chet@google.com>
Date: Wed Jul 05 07:26:46 2023
Convert APIs using PointF to use Float instead
PointF is a convenient mechanism for passing around x.y values
representing 2D points. But there are downsides, including:
- Converting to PointF: You may not have the data in PointF form
to begin with, so using an API which takes PointF requires converting
the data to that form (including allocating a PointF object every time)
- Mutability: Point structures can be mutated internally, causing
unpredictability in what that mutation means. Should the library
react to those changes? Ignore them? Do defensive copies (requiring
even more allocations)? Using primitive types like Float make the
behavior more obvious (by making the data inherently immutable).
- Allocations: Whenever we use object types, there are necessarily
allocations on the Java heap for them. This puts pressure on the GC
at both allocation and collection time. Given the amount of points
being passed around (especially at morph creation time, when curves
are being split and created), this causes a lot of PointF objects to
be allocated (even temporarily). Using Float avoids that problem.
Also fixed bug with unclosed paths causing discontinuity at the
start/end point.
Bug: 276466399
Bug: 290254314
Test: integration and unit tests pass
Relnote: PointF parameters changed to Float pairs
Change-Id: Id4705d27c7be31b26ade8186b99fffe2e2f8450e
M graphics/graphics-shapes/api/current.txt
M graphics/graphics-shapes/api/restricted_current.txt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicShapeTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonMeasureTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/RoundedPolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/ShapesTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/TestUtils.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Cubic.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/CubicShape.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FeatureMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FloatMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Morph.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/PolygonMeasure.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/RoundedPolygon.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Shapes.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Utils.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/DebugDraw.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/ShapeEditor.kt
M graphics/integration-tests/testapp/src/main/java/androidx/graphics/shapes/test/MaterialShapes.kt
je...@google.com
kl...@google.com
PointF was the main (possibly only) mutability issue, marking this as fixed
kl...@google.com
kl...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.graphics:graphics-shapes:1.0.0-alpha04
kl...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 98f2641f492c7ffc91e77e39d60b77909669f0ea
Author: Zach Klippenstein <klippenstein@google.com>
Date: Wed Nov 09 16:48:00 2022
Send apply notifications after Recomposer finishes frame.
This fixes a bug where updating the intrinsics changes would be delayed
a frame. Changes to the intrinsics measure policy in a
layout node during apply changes was not applied until _after_ the
layout pass, which might result in not invalidating layout that should
have been that frame. And since those changes would only be applied for
the next frame, it would invalidate that frame unnecessarily. In other
words, intrinsics changes would be delayed a frame.
This is a prerequisite for
Test: RemeasureWithIntrinsicsRealClockTest (the current test does not
catch this bug because of
Test: RecomposerTests
Relnote: "Snapshot apply notifications are now sent after the
`Recomposer` finishes applying changes."
Change-Id: Iad6c0dcd163a5a8f9c5aec426da3d4f701ca509f
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/Recomposer.kt
M compose/runtime/runtime/src/commonTest/kotlin/androidx/compose/runtime/CompositionTests.kt
M compose/runtime/runtime/src/commonTest/kotlin/androidx/compose/runtime/EffectsTests.kt
M compose/runtime/runtime/src/commonTest/kotlin/androidx/compose/runtime/RecomposerTests.kt
A compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/RemeasureWithIntrinsicsRealClockTest.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/RemeasureWithIntrinsicsTest.kt
https://android-review.googlesource.com/2296013
Branch: androidx-main
commit 98f2641f492c7ffc91e77e39d60b77909669f0ea
Author: Zach Klippenstein <klippenstein@google.com>
Date: Wed Nov 09 16:48:00 2022
Send apply notifications after Recomposer finishes frame.
This fixes a bug where updating the intrinsics changes would be delayed
a frame. Changes to the intrinsics measure policy in a
layout node during apply changes was not applied until _after_ the
layout pass, which might result in not invalidating layout that should
have been that frame. And since those changes would only be applied for
the next frame, it would invalidate that frame unnecessarily. In other
words, intrinsics changes would be delayed a frame.
This is a prerequisite for
Test: RemeasureWithIntrinsicsRealClockTest (the current test does not
catch this bug because of
Test: RecomposerTests
Relnote: "Snapshot apply notifications are now sent after the
`Recomposer` finishes applying changes."
Change-Id: Iad6c0dcd163a5a8f9c5aec426da3d4f701ca509f
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/Recomposer.kt
M compose/runtime/runtime/src/commonTest/kotlin/androidx/compose/runtime/CompositionTests.kt
M compose/runtime/runtime/src/commonTest/kotlin/androidx/compose/runtime/EffectsTests.kt
M compose/runtime/runtime/src/commonTest/kotlin/androidx/compose/runtime/RecomposerTests.kt
A compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/RemeasureWithIntrinsicsRealClockTest.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/RemeasureWithIntrinsicsTest.kt
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit f61c557f4526dfa0e33d070de9c262e788184e8a
Author: Zach Klippenstein <klippenstein@google.com>
Date: Thu Oct 20 10:33:11 2022
Defer dispatching coroutines resumed during animation callbacks in UI tests.
This is a workaround for the fact that we use an unconfined dispatcher
in UI tests (
layout passes for frames in some cases (
TestMonotonicFrameClock gets a continuation interceptor which wraps continuations with
behavior that will usually no-op, but if the continuation is resumed
while frame callbacks are running, it will defer resuming the
underlying continuation until all the frame callbacks have finished.
This matches how continuations are dispatched in non-test code, since
that code does not use an unconfined dispatcher.
In order to preserve test delay skipping, the interceptor implements
Delay and delegates it to the underlying dispatcher, just like
ApplyingContinuationInterceptor is already doing.
This CL also adds a callback that runs after each frame in
TestMonotonicFrameClock. This change was originally in aosp/2121435.
This allows us to perform measure and layout after each frame if
necessary, which aligns the measure/layout timing with production.
Bug:
Bug:
Bug:
Test: PhaseOrderingTest, TestMonotonicFrameClockTest
Relnote: "In UI tests using a Compose rule, continuations resumed during
`withFrameNanos` callbacks will not be dispatched until after all
frame callbacks have finished running. This matches the behavior of
compose when running normally. However, tests that rely on the old
behavior may fail. This should only affect code that calls
`withFrameNanos` or `withFrameMillis` directly, and has logic
outside of callback passed to those functions that may need to be
moved inside the callbacks. See the animation test changes in this
CL for examples."
Relnote: "Added optional `onPerformTraversals: (Long) -> Unit` parameter to
`TestMonotonicFrameClock` constructor and factory function to run
code after `withFrameNanos` callbacks but before resuming callers'
coroutines."
Change-Id: Idb41309445a030c91e8e4ae05daa9642b450505c
M compose/animation/animation-core/src/androidAndroidTest/kotlin/androidx/compose/animation/core/SingleValueAnimationTest.kt
M compose/animation/animation/src/androidAndroidTest/kotlin/androidx/compose/animation/AnimatedContentTest.kt
M compose/animation/animation/src/androidAndroidTest/kotlin/androidx/compose/animation/CrossfadeTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollableFocusableInteractionTest.kt
M compose/test-utils/src/androidMain/kotlin/androidx/compose/testutils/AndroidComposeTestCaseRunner.android.kt
M compose/ui/ui-test-junit4/src/androidMain/kotlin/androidx/compose/ui/test/ComposeUiTest.android.kt
M compose/ui/ui-test-junit4/src/commonMain/kotlin/androidx/compose/ui/test/ApplyingContinuationInterceptor.kt
M compose/ui/ui-test/api/public_plus_experimental_current.txt
M compose/ui/ui-test/src/androidAndroidTest/kotlin/androidx/compose/ui/test/PhaseOrderingTest.kt
M compose/ui/ui-test/src/androidAndroidTest/kotlin/androidx/compose/ui/test/TestMonotonicFrameClockTest.kt
A compose/ui/ui-test/src/commonMain/kotlin/androidx/compose/ui/test/internal/DelayPropagatingContinuationInterceptorWrapper.kt
A compose/ui/ui-test/src/jvmMain/kotlin/androidx/compose/ui/test/FrameDeferringContinuationInterceptor.kt
M compose/ui/ui-test/src/jvmMain/kotlin/androidx/compose/ui/test/TestMonotonicFrameClock.jvm.kt
https://android-review.googlesource.com/2260389
Branch: androidx-main
commit f61c557f4526dfa0e33d070de9c262e788184e8a
Author: Zach Klippenstein <klippenstein@google.com>
Date: Thu Oct 20 10:33:11 2022
Defer dispatching coroutines resumed during animation callbacks in UI tests.
This is a workaround for the fact that we use an unconfined dispatcher
in UI tests (
layout passes for frames in some cases (
TestMonotonicFrameClock gets a continuation interceptor which wraps continuations with
behavior that will usually no-op, but if the continuation is resumed
while frame callbacks are running, it will defer resuming the
underlying continuation until all the frame callbacks have finished.
This matches how continuations are dispatched in non-test code, since
that code does not use an unconfined dispatcher.
In order to preserve test delay skipping, the interceptor implements
Delay and delegates it to the underlying dispatcher, just like
ApplyingContinuationInterceptor is already doing.
This CL also adds a callback that runs after each frame in
TestMonotonicFrameClock. This change was originally in aosp/2121435.
This allows us to perform measure and layout after each frame if
necessary, which aligns the measure/layout timing with production.
Bug:
Bug:
Bug:
Test: PhaseOrderingTest, TestMonotonicFrameClockTest
Relnote: "In UI tests using a Compose rule, continuations resumed during
`withFrameNanos` callbacks will not be dispatched until after all
frame callbacks have finished running. This matches the behavior of
compose when running normally. However, tests that rely on the old
behavior may fail. This should only affect code that calls
`withFrameNanos` or `withFrameMillis` directly, and has logic
outside of callback passed to those functions that may need to be
moved inside the callbacks. See the animation test changes in this
CL for examples."
Relnote: "Added optional `onPerformTraversals: (Long) -> Unit` parameter to
`TestMonotonicFrameClock` constructor and factory function to run
code after `withFrameNanos` callbacks but before resuming callers'
coroutines."
Change-Id: Idb41309445a030c91e8e4ae05daa9642b450505c
M compose/animation/animation-core/src/androidAndroidTest/kotlin/androidx/compose/animation/core/SingleValueAnimationTest.kt
M compose/animation/animation/src/androidAndroidTest/kotlin/androidx/compose/animation/AnimatedContentTest.kt
M compose/animation/animation/src/androidAndroidTest/kotlin/androidx/compose/animation/CrossfadeTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollableFocusableInteractionTest.kt
M compose/test-utils/src/androidMain/kotlin/androidx/compose/testutils/AndroidComposeTestCaseRunner.android.kt
M compose/ui/ui-test-junit4/src/androidMain/kotlin/androidx/compose/ui/test/ComposeUiTest.android.kt
M compose/ui/ui-test-junit4/src/commonMain/kotlin/androidx/compose/ui/test/ApplyingContinuationInterceptor.kt
M compose/ui/ui-test/api/public_plus_experimental_current.txt
M compose/ui/ui-test/src/androidAndroidTest/kotlin/androidx/compose/ui/test/PhaseOrderingTest.kt
M compose/ui/ui-test/src/androidAndroidTest/kotlin/androidx/compose/ui/test/TestMonotonicFrameClockTest.kt
A compose/ui/ui-test/src/commonMain/kotlin/androidx/compose/ui/test/internal/DelayPropagatingContinuationInterceptorWrapper.kt
A compose/ui/ui-test/src/jvmMain/kotlin/androidx/compose/ui/test/FrameDeferringContinuationInterceptor.kt
M compose/ui/ui-test/src/jvmMain/kotlin/androidx/compose/ui/test/TestMonotonicFrameClock.jvm.kt
kl...@google.com
Since this bug is in the test runtime, you might expect that fixing it would expose actual bugs that tests weren't catching, because they weren't able to. And it did!
- Coroutine continuations were being dispatched immediately even during frame callbacks (
b/254115946 b/255802670 - Intrinsics were writing a state object in applyChanges that was not getting picked up until the next frame, this was a bug in
Recomposer(aosp/2296013). - The
ConstraintLayoutcomposable was triggering an additional, unnecessary recomposition whenever a helper changed (b/261270254
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 9f9434a17870acd76c6c692dab9ffa425d1eab04
Author: Zach Klippenstein <klippenstein@google.com>
Date: Sat Dec 03 08:00:35 2022
Fix ConstraintLayout causing extra recomposition when helper changes.
Fixes:
Bug:
Test: ConstraintLayoutTest
Relnote: "Fixed issue where ConstraintLayout always triggered an
unnecessary extra recomposition when helpers were changed."
Change-Id: Id83ada3e963b20180c324f25b6db7c53f810463f
M constraintlayout/constraintlayout-compose/src/androidAndroidTest/kotlin/androidx/constraintlayout/compose/ConstraintLayoutTest.kt
M constraintlayout/constraintlayout-compose/src/androidMain/kotlin/androidx/constraintlayout/compose/ConstraintLayout.kt
https://android-review.googlesource.com/2319364
Branch: androidx-main
commit 9f9434a17870acd76c6c692dab9ffa425d1eab04
Author: Zach Klippenstein <klippenstein@google.com>
Date: Sat Dec 03 08:00:35 2022
Fix ConstraintLayout causing extra recomposition when helper changes.
Fixes:
Bug:
Test: ConstraintLayoutTest
Relnote: "Fixed issue where ConstraintLayout always triggered an
unnecessary extra recomposition when helpers were changed."
Change-Id: Id83ada3e963b20180c324f25b6db7c53f810463f
M constraintlayout/constraintlayout-compose/src/androidAndroidTest/kotlin/androidx/constraintlayout/compose/ConstraintLayoutTest.kt
M constraintlayout/constraintlayout-compose/src/androidMain/kotlin/androidx/constraintlayout/compose/ConstraintLayout.kt
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 0253b7d395277c6a4669cbcb1ff7bdc5583cb6c6
Author: Zach Klippenstein <klippenstein@google.com>
Date: Tue Nov 22 14:33:04 2022
Make UI tests run layout passes between frames
Checks if a local measure/layout is scheduled after execution of each
frame. With a local measure/layout I mean a layout pass for which an
Android View layout pass has not been scheduled. It is local because it
only affects composables, and not any View outside the host View.
Fixes:
Bug:
Test: AnimatedVisibilityTest (new in ui-test-junit4)
Test: PhaseOrderingTest
Test: TestRuleExecutesLayoutPassesWhenWaitingForIdleTest
Test: BasicCurvedTextTest
Test: this change is also exercised by nearly all tests
Relnote: "Android Compose UI tests will now run layout passes for each frame when
executing frames to get to idle (e.g. via `waitForIdle`). This may
affect tests that assert on individual frames of layout animations."
Change-Id: I8ea08728a395665f9ec7965579797e537b2c35e5
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/BackdropScaffoldTest.kt
M compose/ui/ui-test-junit4/build.gradle
M compose/ui/ui-test-junit4/src/androidMain/kotlin/androidx/compose/ui/test/ComposeUiTest.android.kt
M compose/ui/ui-test/src/androidAndroidTest/kotlin/androidx/compose/ui/test/PhaseOrderingTest.kt
M compose/ui/ui/api/public_plus_experimental_current.txt
A compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/TestRuleExecutesLayoutPassesWhenWaitingForIdleTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.android.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/RootForTest.kt
M wear/compose/compose-foundation/src/androidAndroidTest/kotlin/androidx/wear/compose/foundation/BasicCurvedTextTest.kt
https://android-review.googlesource.com/2243539
Branch: androidx-main
commit 0253b7d395277c6a4669cbcb1ff7bdc5583cb6c6
Author: Zach Klippenstein <klippenstein@google.com>
Date: Tue Nov 22 14:33:04 2022
Make UI tests run layout passes between frames
Checks if a local measure/layout is scheduled after execution of each
frame. With a local measure/layout I mean a layout pass for which an
Android View layout pass has not been scheduled. It is local because it
only affects composables, and not any View outside the host View.
Fixes:
Bug:
Test: AnimatedVisibilityTest (new in ui-test-junit4)
Test: PhaseOrderingTest
Test: TestRuleExecutesLayoutPassesWhenWaitingForIdleTest
Test: BasicCurvedTextTest
Test: this change is also exercised by nearly all tests
Relnote: "Android Compose UI tests will now run layout passes for each frame when
executing frames to get to idle (e.g. via `waitForIdle`). This may
affect tests that assert on individual frames of layout animations."
Change-Id: I8ea08728a395665f9ec7965579797e537b2c35e5
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/BackdropScaffoldTest.kt
M compose/ui/ui-test-junit4/build.gradle
M compose/ui/ui-test-junit4/src/androidMain/kotlin/androidx/compose/ui/test/ComposeUiTest.android.kt
M compose/ui/ui-test/src/androidAndroidTest/kotlin/androidx/compose/ui/test/PhaseOrderingTest.kt
M compose/ui/ui/api/public_plus_experimental_current.txt
A compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/TestRuleExecutesLayoutPassesWhenWaitingForIdleTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.android.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/RootForTest.kt
M wear/compose/compose-foundation/src/androidAndroidTest/kotlin/androidx/wear/compose/foundation/BasicCurvedTextTest.kt
ju...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.animation:animation:1.4.0-alpha03androidx.compose.animation:animation-core:1.4.0-alpha03androidx.compose.foundation:foundation:1.4.0-alpha03androidx.compose.runtime:runtime:1.4.0-alpha03androidx.compose.ui:ui:1.4.0-alpha03androidx.compose.ui:ui-test:1.4.0-alpha03androidx.compose.ui:ui-test-junit4:1.4.0-alpha03
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material:material:1.4.0-alpha04androidx.compose.ui:ui:1.4.0-alpha04androidx.compose.ui:ui-test:1.4.0-alpha04androidx.compose.ui:ui-test-junit4:1.4.0-alpha04androidx.wear.compose:compose-foundation:1.2.0-alpha02
pr...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.constraintlayout:constraintlayout-compose:1.1.0-alpha06
Description
When we're awaiting idleness, we forward ("pump") the clock to reach quiescence faster. But in many cases we also have to wait for measure/layout, which is still driven by the Choreographer. If we can perform a measure/layout pass ourselves when we detect that's the thing we're waiting for, we can potentially reach idleness faster.