Assigned
Status Update
No update yet.
Comments
mi...@gmail.com
Comment has been deleted.
mi...@gmail.com
Comment has been deleted.
mi...@gmail.com
Comment has been deleted.
mi...@gmail.com
Comment has been deleted.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 2aeb1ef6df87be355a142908665d523b12a6875a
Author: Louis Pullen-Freilich <lpf@google.com>
Date: Fri Mar 03 17:23:05 2023
Avoids extra recomposition inside ProvideAndroidCompositionLocals
Workaround for a bug where this state read is invalidated even though we only set the value before setContent is called - before the separate change (aosp/2467340) to optimize LocalConfiguration, this meant that every call to LocalConfiguration was getting called twice on first composition.
Bug:
Test: manual
Change-Id: I3a02be43fc361a0df212df4c6f8e00bef3992f9d
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.android.kt
https://android-review.googlesource.com/2469921
Branch: androidx-main
commit 2aeb1ef6df87be355a142908665d523b12a6875a
Author: Louis Pullen-Freilich <lpf@google.com>
Date: Fri Mar 03 17:23:05 2023
Avoids extra recomposition inside ProvideAndroidCompositionLocals
Workaround for a bug where this state read is invalidated even though we only set the value before setContent is called - before the separate change (aosp/2467340) to optimize LocalConfiguration, this meant that every call to LocalConfiguration was getting called twice on first composition.
Bug:
Test: manual
Change-Id: I3a02be43fc361a0df212df4c6f8e00bef3992f9d
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.android.kt
ch...@google.com
al...@google.com
Triage notes: Has a workaround, P3 backlog for now. We want to look into this, but we may end up just providing a recommendation rather than a CL.
Description
There is a mutable state we create during the initialization of the view. Then there is onAttachedToWindow() callback from which we update this state and only after that we call composition.setContent {}.
Inside this content composable we read this mutable state. And even that during the initial composition we already got the correct updated value after that one more recomposition is scheduled. Such recomposition is not needed as the mutation happened before we do the composition.
Seems like the issue is that inside Recomposer we do not synchonously invalidate the composition when the apply callback happened. Instead we collect the changed objects in a set and wait for the next recomposition. While we wait the composition is initialized. And then on the next frame we find that the new composition use the object which was changed and schedule a recomposition.
it is important that after the mutable state creation we will advance to a new snapshot, so the change is not considered as the one happened in the same snapshot in which it was created and no extra recomposition is scheduled.
We found a workaround for this exact issue with use of derivedStateOf(), but it will be great if we can find a way to not do such unnecessary recompositions.