Bramus from Chrome DevRel describes an optimization that Chrome's got on Canary right now: See https://www.bram.us/2025/11/13/animating-css-width-or-height-no-longer-force-a-main-thread-animation-in-chrome-under-the-right-conditions/ Essentially: * `height` and `width` animations run on the main thread. * View transitions [generate animations for 'height' and 'width'](https://drafts.csswg.org/css-view-transitions/#::view-transition-group) * In some cases, those values don't actually change at all, which means the view-transition animations aren't really doing anything. * So: if we can detect those, it'd be great to optimize them away entirely (or consider them to be handled by the compositor). This would help us avoid needlessly updating style & painting at 60FPS for what is actually a no-op animation.
Bug 2000047 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Bramus from Chrome DevRel describes an optimization that Chrome's got on Canary right now: See https://www.bram.us/2025/11/13/animating-css-width-or-height-no-longer-force-a-main-thread-animation-in-chrome-under-the-right-conditions/ Essentially: * `height` and `width` animations run on the main thread. * View transitions [generate animations for 'height' and 'width'](https://drafts.csswg.org/css-view-transitions/#::view-transition-group) * In some cases, those values don't actually change at all, which means the view-transition animations aren't really doing anything. * So: if we can detect those, it'd be great to optimize them away entirely (or consider them to be handled by the compositor). This would help us avoid needlessly running animation callback code at 60FPS on the main thread, for what is actually a no-op animation.
Bramus from Chrome DevRel describes an optimization that Chrome's got on Canary right now: See https://www.bram.us/2025/11/13/animating-css-width-or-height-no-longer-force-a-main-thread-animation-in-chrome-under-the-right-conditions/ Essentially: * `height` and `width` animations run on the main thread. * View transitions [generate animations for 'height', 'width', and 'transform'](https://drafts.csswg.org/css-view-transitions/#::view-transition-group) * In some cases, the 'height' and 'width' values don't actually change at all, which means the view-transition animations aren't really doing anything for those properties. * So: if we can detect and specially-handle those, it'd be great to optimize them away entirely (or consider them to be handled by the compositor). This would help us avoid needlessly running animation callback code at 60FPS on the main thread, for what is actually a no-op animation.
Bramus from Chrome DevRel describes an optimization that Chrome's got on Canary right now: See https://www.bram.us/2025/11/13/animating-css-width-or-height-no-longer-force-a-main-thread-animation-in-chrome-under-the-right-conditions/ Essentially: * `width` and `height` animations run on the main thread. * View transitions [generate animations for `width`, `height`, and `transform`](https://drafts.csswg.org/css-view-transitions/#::view-transition-group) * In some cases, the `width` and `height` values don't actually change at all, which means the view-transition animations aren't really doing anything for those properties. * So: if we can detect and specially-handle those, it'd be great to optimize them away entirely (or consider them to be handled by the compositor). This would help us avoid needlessly running animation callback code at 60FPS on the main thread, for what is actually a no-op animation.