[anchor] Main thread animation if first frame doesn't change anything. #57230
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-7451459
branch
from
329d455 to
62946a1
Compare
This is a follow-up to https://crrev.com/c/7123703 , but it was blocked on other problems, which got fixed by https://crrev.com/c/7239030 . We can now get anchor animations that don't change any styles right away (i.e. no visual updates until further into the animation) to trigger relayout of anchor-positioned elements when needed. If the very first animation frame actually has style changes that affect layout (e.g. transforms that affect an anchor), we still haven't moved the work off the main thread, and we'll therefore lay out, and by doing that, HasRunningAnchorTransformAnimation() in PhysicalFragment will return true, which in turn will make sure that the animation keeps running on the main thread. This was already working. On the other hand, if the first frame of an animation *doesn't* change style that affects layout, the animation would be moved to the compositor thread, and we'd never hear from it again, not even when any style changes actually occur later on. To fix this, detect that a transform-related animation wants to run on the compositor, mark for layout, so that the physical fragments get updated for HasRunningAnchorTransformAnimation(), so that we'll be able to keep the animation on the main thread Note: The test included would only fail with run_wpt_tests, not run_web_tests. Bug: 382294252 Change-Id: I193c354f0e28b4b908d75ce1b200c2c8142be43c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7451459 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1571069}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-7451459
branch
from
62946a1 to
2e80077
Compare
wpt-pr-bot
approved these changes
Jan 19, 2026
Collaborator
wpt-pr-bot
left a comment
wpt-pr-bot
left a comment
There was a problem hiding this comment.
The review process for this patch is being conducted in the Chromium project.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is a follow-up to https://crrev.com/c/7123703 , but it was blocked
on other problems, which got fixed by https://crrev.com/c/7239030 . We
can now get anchor animations that don't change any styles right away
(i.e. no visual updates until further into the animation) to trigger
relayout of anchor-positioned elements when needed.
If the very first animation frame actually has style changes that affect
layout (e.g. transforms that affect an anchor), we still haven't moved
the work off the main thread, and we'll therefore lay out, and by doing
that, HasRunningAnchorTransformAnimation() in PhysicalFragment will
return true, which in turn will make sure that the animation keeps
running on the main thread. This was already working.
On the other hand, if the first frame of an animation doesn't change
style that affects layout, the animation would be moved to the
compositor thread, and we'd never hear from it again, not even when any
style changes actually occur later on. To fix this, detect that a
transform-related animation wants to run on the compositor, mark for
layout, so that the physical fragments get updated for
HasRunningAnchorTransformAnimation(), so that we'll be able to keep the
animation on the main thread
Note: The test included would only fail with run_wpt_tests, not
run_web_tests.
Bug: 382294252
Change-Id: I193c354f0e28b4b908d75ce1b200c2c8142be43c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7451459
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1571069}