Fix a crash by PaintWorklet + custom property animation #26611
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://chromium-review.googlesource.com/c/chromium/src/+/2359370
The above CL made a custom property animation always composited if
it is used by paint worklet, even if the element does not have
"will-change: transform". The approach is that we give a special
ElementId which is uint64_t::max() to the paint worklet element,
and then on the CC side, once we see that element id, we know that
it is an animation associated with paint worklet and we will always
tick that animation.
The problem comes when there are two paint worklet elements.
The short version of the problem is:
CC's animation system doesn't allow two layers with the same
ElementId.
Longer version:
Then these two layers would have the same ElementId when
we try to attach a composited layer with that animation. As a
result, in the AnimationHost::RegisterAnimationForElement(), we
will have two Animation with the same ElementId. Then, the actual
crash happens at ElementAnimations::GetPropertyToElementIdMap(),
at the first DCHECK.
So the solution in this CL is to not DCHECK in certain cases.
The DCHECK actually doesn't make sense in this case where
there is no composited layer. In fact, the callers of the
ElementAnimations::GetPropertyToElementIdMap gives the result
to MutatorHostClient::ElementIsAnimatingChanged, and in there
it only cares about 4 properties. So for the other properties
that it doesn't care, we should not put it in the map.
Bug: 1151755
Change-Id: I5479ccae80f3c89db98d27518ef013dded527ece
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2553691
Commit-Queue: Xida Chen <xidachen@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#831090}