-
Notifications
You must be signed in to change notification settings - Fork 48.8k
Clear width/height from Keyframes to Optimize View Transitions #33576
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
Conversation
Comparing: a947eba...447700e Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
The benefits here are obvious (run on compositor thread) What are the downsides? Or why wouldn't browsers do this automatically? Is it basically just spec compliance that |
Yes, the spec mandates it – See step 3.9.5 of “Setup transition pseudo-elements”.
I had suggested this optimization in w3c/csswg-drafts#11657 but retracted my suggestion as it would result in the keyframes no longer being predictable for devs to extract info from. Maybe we should revisit that. |
Having predictable keyframes would be nice. Ofc there's still many bugs that makes that not the case anyway. However, given the choice between having optimizable animations (especially on iOS where the difference results in 60fps vs 120fps even ignoring main thread jank), the choice is going to be to default to optimizable every time. If we can have both that would be best. So making the implementation optimizable would be best. However, I don't have high hopes for all implementations to actually do the work to do that (Safari). A change to the default keyframes seems smaller in scope for implementors. Until then it's up to JS frameworks to provide the best possible default given the current state of browsers. |
View Transitions has this annoying quirk where it adds `width` and `height` to keyframes automatically when generating keyframes even when it's not needed. This causes them to deopt from running on the compositor thread in both Chrome and Safari. @bramus has a [good article on it](https://www.bram.us/2025/02/07/view-transitions-applied-more-performant-view-transition-group-animations/). In React we can automatically rewrite the keyframes when we're starting a View Transition to drop the `width` and `height` from the keyframes when they have the same value and the same value as the pseudo element. To compare it against the pseudo element we first apply the new keyframes without the width/height and then read it back to see if it has changed. For gestures, we have already cancelled the previous animation so we can just read out from that. DiffTrain build for [c0d151c](c0d151c)
View Transitions has this annoying quirk where it adds
width
andheight
to keyframes automatically when generating keyframes even when it's not needed. This causes them to deopt from running on the compositor thread in both Chrome and Safari. @bramus has a good article on it.In React we can automatically rewrite the keyframes when we're starting a View Transition to drop the
width
andheight
from the keyframes when they have the same value and the same value as the pseudo element.To compare it against the pseudo element we first apply the new keyframes without the width/height and then read it back to see if it has changed. For gestures, we have already cancelled the previous animation so we can just read out from that.