1876263 - See how much we can optimize `all` transition handling.

Status: NEW

(Core :: CSS Transitions and Animations, task)

Description

[Emilio Cobos Álvarez [:emilio]]

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.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

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

[Boris Chiou [:boris]]

(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 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?

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).