+553
−0
+477
−0
File added.
Preview size limit exceeded, changes collapsed.
File changed.
Preview size limit exceeded, changes collapsed.
Loading
Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more
Previously, withFrameNanos was only guaranteed to run frames back-to-back while there was an animation running (derived from `!isStable`). Otherwise, the loop might have been suspended in `wakeupChannel.receive()` while in practice it was not. This change has multiple implications # No side-effects until the beginning of the next frame Deferring the update of the "last*" state to the beginning of the new frame ensures that reads of output do not trigger a re-computation. This fixes b/391259026, since MotionValues depending on the output of other motion values will not trigger a recomputation when they capture the `currentInput` after a frame. # Velocity computation Knowing that the animation loop is active on input/state change allows to compute a change velocity, and enables fixing b/379612686 in a follow-up CL # Simpler suspension This change removes the complexity of the snapshotFlow/channel/coroutine scheduling, keeping a tight withFrameAnimation loop while there are any changes, and suspending while there are none. Whenever compose sees changes in the SnapshotState, an Choreographer frame is requested anyways, so the MotionValue does not request additional animation frames, unless it is actually animating. With this change, there is one extra, trailing withFrameNanos being scheduled, to determine that there are no more changes. Fixed: 391259026 Fixed: 383979536 Test: MotionValueTest Flag: com.android.systemui.scene_container Change-Id: Iaf72a5f60b51c303366fc193d98a56a4a12f6177
File added.
Preview size limit exceeded, changes collapsed.
File changed.
Preview size limit exceeded, changes collapsed.