[Webkit-unassigned] [Bug 206280] Do not detect the stopped animations in Nicosia::Animation to avoid flashback

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jan 16 06:45:58 PST 2020


--- Comment #3 from Miguel Gomez <magomez at igalia.com> ---
I see what happens here.

On a proper execution, CSSAnimationController sets an animation to the CoordinatedGraphicsLayer, which is flushed to the appropriate TextureMapperLayer, and several compositions happen in the compositor until the animation is over. At that point the CSSAnimationController removes the animation from the CoordinatedGraphicsLayer, that's flushed to the TextureMapperLayer and the animation is gone.

The problem is that a new composition may happen after the animation is finished on the compositor side, but the CSSAnimationController didn't have time to propagate the removal of the animation to the TextureMapperLayer. In the morphing cubes example this extra composition is probably caused by the other animations running (as the finished one won't request more compositions).

This extra composition happens when the animation is over on the compositor side, so the animation transform is not applied and the TextureMapperLayer is painted where it was before the animation, and there's the flashback.

The idea of the patch looks good: basically always apply the animation until it's removed by the CSSAnimationController. This causes that even if the animation is over, the TextureMapperLayer will be painted in the last position of the animation until it gets removed, which makes sense. Also, this is not causing extra composition requests, because in order to decide whether there are animations ongoing to request more compositions we check whether there are animations in the playing state and not whether they are active.

Keeping the last animation transform until it's removed by CSSAnimationController doesn't seem to cause any visual regression (I tried several tests to check) and it doesn't cause regressions on the layout tests, so it looks good to me.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200116/4f44cd3f/attachment-0001.htm>

More information about the webkit-unassigned mailing list