tree 637719ba2276775ec6706794923a87b00d39e928
parent 88fbd425a85fbba6365976ca9b056c719f7685a5
author Jorim Jaggi <jjaggi@google.com> 1527522232 +0200
committer Jorim Jaggi <jjaggi@google.com> 1527769319 +0200

Push existing pending state when deferring transaction

Otherwise the information from another transaction that happened
before deferring the transaction could have been deferred as well.
To fix that, we push the currently pending state if the
transaction is deferred.

Furthermore, we need to modify the behavior how flags are applied.
Imagine the following sequence of events
- Surface is hidden flags=hidden
- t1 doesn't modify the flags (0/0) but sets some other properties.
flags=hidden mask=0. mCurrentState gets pushed onto mPendingState
before t2 sets (0/hidden) (flags/mask) flags=0 mask=hidden, to
show the surface. Furthemore, we defer this transaction.
mCurrentState gets pushed onto mPendingState.
- At this point, mCurrentState.flags = 0 (shown), but
mDrawingState.flags = hidden
- doTransaction happens. c (the state to promote to drawing state)
= mCurrentState => c.flags = 0 (shown)
Since t1 isn't deferred, the 0th element of mPendingState gets
popped and applied to c. Since mask=0, c.flags = 0 still.
- c gets promoted to mDrawingState and BOOM the
surface was shown even though the barrier of the transaction
showing hasn't opened yet.

Looking closer at the logic it makes sense to just apply the mask
when modifying the current state, and then just pushing it like
all other attributes.

Test: go/wm-smoke
Bug: 78611607
Change-Id: Ia100532189ef7f59f8939c59db9b6292b41e8e77