tree ddad3f7e14d96e213863fe3a922505c48abba414
parent abee62b65c510c4ca289d94992a233fd49bd41a0
author Galia Peycheva <galinap@google.com> 1667990782 +0100
committer Galia Peycheva <galinap@google.com> 1667992685 +0000

Fix pip update transaction out of order

When a resize animation is playing,
PipAnimationController#onAnimationUpdate is called with the fraction
of the animation progress. This fraction is used to calculate a scale
value (in a matrix), which is applied in a transaction to the pip
surface. This scaling is invisible to WmCore, so the bounds of the
pip surface are still the bounds before the animation began. In SF,
those bounds are scaled and drawn using that matrix. When the
animation is finished, onAnimationEnd is called. onAnimationEnd is
special, because it finishes the resizing and sends the updated pip
task bounds to WmCore in a WindowContainerTransaction. The
WindowContainerTransaction is applied separately by WmCore.

To animate the PiP surface together with the PiP menu, the
transaction forged by onPipAnimationUpdate should be synchronized with
the corresponding transaction applied on the PiP menu surface. The PiP
menu content also has to redraw in the new bounds. These three events
need to be synchronized, otherwise the animation would look janky.
To synchronize them, the PipMenuController introduces a delay, waiting
until the next draw is complete before merging the PiP surface + PiP
menu surface transactions into the global transaction for the same
frame.

This happens in every onPipAnimationUpdate callback. The
onPipAnimationEnd, however, is different. It has to commit the resize
to WmCore, so it doesn't follow the same code path as the transactions
created on inPipAnimationUpdate. In onPipAnimationEnd the resize is
finished by creating a WindowContainerTransaction and sending it to
WmCore to update the size of the PiP task window container. The WCT
is then applied by the WmCore at some later point in time.

The race condition we are fighting with this CL happens because the
transaction created by the last onPipAnimationUpdate may get applied
*after* the WindowContainerTransaction created by onPipAnimationEnd.
We have no way to synchronize those two transactions, because the
onPipAnimationUpdate one is applied by WmShell, while the
onPipAnimationEnd one is applied by WmCore. In some rare cases, they
might get applied out of order and the PiP surface ends up in this weird
state where an extra scale was applied to it.

To address this, we delay finishing the resize (and creating+sending
the WindowContainerTransaction to WmCore) in onPipAnimationEnd to the
next frame, which aligns it better with when the transaction from the
last onPipAnimationUpdate is applied. Applying onPipAnimationUpdate is
also delayed one frame, because it waits for the Pip menu content
to be drawn for that frame. So introducing the same one-frame-delay
for the finishResize makes sure that it can't happen before the
transaction from the last onPipAnimationUpdate

Bug: 228317396
Test: manual - change pip aspect ratio several times
Change-Id: Ieb7020d329ffe6f1a4c61a22eae65e2b36feb211