CSS transitions and animations should be visible with profiler markers
Categories
(Core :: CSS Transitions and Animations, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox88 | --- | fixed |
People
(Reporter: florian, Assigned: florian)
References
Details
Attachments
(1 file)
It would be useful to have profiler makers to see how many transitions are running, when, for how long, on which properties.
|
Assignee | |
Comment 1•3 years ago
|
||
|
|
Assignee | |
Comment 2•3 years ago
|
||
Example profile with the markers added by the patch: https://share.firefox.dev/3exanJr
Pushed by fqueze@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/18f24adbf3b5 CSS transitions and animations should be visible with profiler markers, r=emilio.
|
||
Comment 4•3 years ago
|
||
| bugherder | ||
|
||
Comment 5•3 years ago
|
||
Any reason this only looks at cancel events for CSS animations and not end events?
|
||
Comment 6•3 years ago
|
||
(In reply to Brian Birtles (:birtles) from comment #5)
Any reason this only looks at cancel events for CSS animations and not end events?
Florian?
|
|
Assignee | |
Comment 7•3 years ago
|
||
(In reply to Brian Birtles (:birtles) from comment #5)
Any reason this only looks at cancel events for CSS animations and not end events?
No good reason. My test cases only had animations with infinite iteration counts, so I missed the case of animations that can end without being canceled. I filed bug 1698600 to fix, thanks for pointing this out.
|
|
||
Comment 8•3 years ago
|
||
One caveat about animation performance I should have called out here is we have two major optimizations, animations running on the compositor and fully-throttled animations.
The compositor one is, I believe, well-known, it doesn't consume main-thread works, but there are some restrictions animations are not able to run on the compositor.
The fully-throttled one is we completely skip most of works in the case where the animation's target element is invisible, it doesn't consume the main-thread or the compositor thread either.
Those animations, of course, fire animation events, so even if there are animation event markers in profiles, we can't tell easily the animations in question are performance concerns or not.
|
|
Assignee | |
Comment 9•3 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #8)
One caveat about animation performance I should have called out here is we have two major optimizations, animations running on the compositor and fully-throttled animations.
Showing which optimization has been used for the animation might be an interesting additional information to add to the animation markers in the future. I'm not sure if this information is easily accessible from the code I touched to add the markers, but if we could show in the marker why it was not possible to optimize a specific animation, that might be very valuable for CSS authors.
Those animations, of course, fire animation events, so even if there are animation event markers in profiles, we can't tell easily the animations in question are performance concerns or not.
Profiler markers are often used to understand what's happening, not necessarily only things that are performance concerns. Actually, in this specific case, what made me want to add markers for CSS transitions is that when profiling some automated tests, it wasn't always clear why we had some amount of time with low CPU use, followed by the test doing things again. The new CSS transition markers help me understand at a glance that the test is waiting for the transition to finish.
Description
•