commit d3b5e81317d84b857ca1a653cf9811c11fc79ea7
author Xida Chen <xidachen@chromium.org> Wed Mar 17 04:21:50 2021
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> Wed Mar 17 04:43:33 2021
tree c3fc8e9be9e4951a646401250392207cfc5d1361
parent 423f1072b46b978c1e280452e647394475542fa3

[composite-bgcolor-animation] Decouple paint and compositing

Currently, the CheckCanStartAnimationOnCompositor is called twice
for composite background-color animation, once during paint time
and once during the compositing stage. The reason is that we
need the decision during paint and compositing consistent. That
is, if the paint stage says the background color must be paint
on the main thread, then compositing stage has to agree with
that, and vice versa. However, this is dangerous because between
the paint and compositing stage, things could change, especially
the PaintArtifactCompositor, which is used by the
CheckCanStartAnimationOnCompositor. For example, it could
happen that at paint time we have not produced / updated the
property nodes for the current frame and we can make decision
based on what was composited on the previous frame. Then
at Precommit we have potentially updated / added / removed
property tree nodes. In this case, the return value of
CheckCanStartAnimationOnCompositor can be different, as a
result, the background color animation won't run correctly.

The reason we needed to know whether the animation could be
composited here is that we didn't have a way to paint
the background color off the main thread. More specifically,
the BackgroundColorPaintWorklet::Paint() function can paint the
background color only if the animation is running on the
compositor thread.

This CL makes following changes:
1. Make the BackgroundColorPaintWorklet::Paint() have the
ability to paint the background color even if the animation is
running on the main thread. The function needs two things:
the current progress of the animation and the artifacts about
the animation. So all we need is just getting the progress
when the animation is running on the main thread.
2. With #1 being done, we no longer need to call the
CheckCanStartAnimationOnCompositor during the paint step.
As a result, whether or not the animation can be running on
the compositor thread is solely the decision during the
compositing stage. This is much safer than the current code,
because we no longer need to make a compositing decision during
the paint stage.

We don't need to add any new tests because we already have
sufficient layout tests for background color animation being
run on the compositor as well as on the main thread. As long
as all tests pass, this should be safe.

The main benefit of this change is that the code is now more
robust, meaning that we don't need to worry about the decision
made by the paint and compositing stage being different.
This change is also a performance win because we no longer
need to call the CheckCanStartAnimationOnCompositor twice.

Bug: 1185272, 1182261
Change-Id: Ie072714fd1d05e6537e05cad45ad1da99e20125b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2740697
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#863622}