Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix a crash by PaintWorklet + custom property animation #26611

Merged
merged 1 commit into from Nov 25, 2020

Conversation

@chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented Nov 23, 2020

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}

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

The review process for this patch is being conducted in the Chromium project.

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-2553691 branch 9 times, most recently from cd35663 to 6db55e2 Nov 23, 2020
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}
@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-2553691 branch from 6db55e2 to d09a847 Nov 25, 2020
@chromium-wpt-export-bot chromium-wpt-export-bot merged commit 8225f74 into master Nov 25, 2020
22 checks passed
22 checks passed
Azure Pipelines Build #20201125.42 succeeded
Details
Azure Pipelines (./wpt test-jobs) ./wpt test-jobs succeeded
Details
Azure Pipelines (affected tests without changes: Safari Technology Preview) affected tests without changes: Safari Technology Preview succeeded
Details
Azure Pipelines (affected tests: Safari Technology Preview) affected tests: Safari Technology Preview succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests) wpt.fyi hook: safari-preview-affected-tests succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests-without-changes) wpt.fyi hook: safari-preview-affected-tests-without-changes succeeded
Details
download-firefox-nightly Community-TC (pull_request)
Details
lint Community-TC (pull_request)
Details
sink-task Community-TC (pull_request)
Details
staging.wpt.fyi - chrome[experimental] Chrome results
Details
staging.wpt.fyi - firefox[experimental] Firefox results
Details
staging.wpt.fyi - safari[experimental] Safari results
Details
wpt-chrome-dev-results Community-TC (pull_request)
Details
wpt-chrome-dev-results-without-changes Community-TC (pull_request)
Details
wpt-chrome-dev-stability Community-TC (pull_request)
Details
wpt-decision-task Community-TC (pull_request)
Details
wpt-firefox-nightly-results Community-TC (pull_request)
Details
wpt-firefox-nightly-results-without-changes Community-TC (pull_request)
Details
wpt-firefox-nightly-stability Community-TC (pull_request)
Details
wpt.fyi - chrome[experimental] Chrome results
Details
wpt.fyi - firefox[experimental] Firefox results
Details
wpt.fyi - safari[experimental] Safari results
Details
@chromium-wpt-export-bot chromium-wpt-export-bot deleted the chromium-export-cl-2553691 branch Nov 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants