See how much we can optimize `all` transition handling.
Categories
(Core :: CSS Transitions and Animations, task)
Tracking
()
People
(Reporter: emilio, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [sp3])
https://github.com/WebKit/WebKit/commit/66eb8a0eb60e88dc4a31d1ee690e7fe132267708 claims a big speedometer win by doing something like this.
I'm not quite sure the same applies to us in the sense that ConsiderInitiatingTransition
should bail out relatively early if the values haven't changed (and WebKit didn't have a similar code-path it seems).
But it seems we could still optimize some of it.
Updated•8 months ago
|
Updated•8 months ago
|
Reporter | ||
Comment 1•8 months ago
|
||
So in the profiles from bug 1850809 comment 4, there are some bits that are related. In particular might_need_transitions_update
shows up a lot.). This is on NewsSite, which uses a transition: all .3s ease
for a lot of elements.
An interesting approach here could be to rejigger the code a little bit. We call process_animations before diffing the old and new styles.
For all
transitions, it might be worth calling accumulate_damage_for
first between the old style and the after change style, then using that as an input if you have an all
transition to skip checking all properties. Boris, thoughts about it / anything I might have missed / anything from the profile?
Might not be the cleanest tho... I need to think a bit more about it, but seems it could be workable?
Comment 2•8 months ago
•
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)
So in the profiles from bug 1850809 comment 4, there are some bits that are related. In particular
might_need_transitions_update
shows up a lot.). This is on NewsSite, which uses atransition: all .3s ease
for a lot of elements.An interesting approach here could be to rejigger the code a little bit. We call process_animations before diffing the old and new styles.
For
all
transitions, it might be worth callingaccumulate_damage_for
first between the old style and the after change style, then using that as an input if you have anall
transition to skip checking all properties. Boris, thoughts about it / anything I might have missed / anything from the profile?Might not be the cleanest tho... I need to think a bit more about it, but seems it could be workable?
Ya. all
is used pretty often, so if we could optimize it, we definitely can have better performance in lots of website.
I'm not sure the detail of accumulate_damage_for
, but it sounds OK with me because it might be a faster way to calculate the difference for all longhand properties (though we still have to check all properties on Gecko side for handling creation and cancellation, or perhaps only need for cancellation if we can make sure which transition properties need to be created).
Description
•