1371101 - Run color, border-color, and background-color animations off the main thread

Status: NEW

(Core :: Graphics: WebRender, enhancement, P5)

Description

[Patrick Walton (:pcwalton)]

With WebRender we should be able to render color animations off the main thread. The Chrome folks have some great empirical data showing how often Web pages do this: https://www.chromestatus.com/metrics/css/animated

Animating these properties OMT would bring the number of OMT animations in the wild from 58.3% to 74.9%, a gain of 16.6%.

Comment 1

[Patrick Walton (:pcwalton)]

Proposed list of properties: color, background-color, border-top-color, border-right-color, border-bottom-color, border-left-color, outline-color.

Comment 2

[Hiroyuki Ikezoe (:hiro)]

FWIW, in my spare time, I've just started making background-color (the third most popular as per the chrome status site) animations run on the compositor on *non-WebRender*.

Though I don't know the reasons why we can't run background-color on the compositor in the case of non-WebRender, it looks well so far.  Even there are some reasons, we can make it work with some restrictions for some cases?
 
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ea657c879fdfbaf2122e85132dd000bf664a7cdc&selectedJob=189506974

Comment 3

[Markus Stange [:mstange]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)
> Though I don't know the reasons why we can't run background-color on the
> compositor in the case of non-WebRender

I'm not aware of any reasons. I was planning to do this some time ago for bug 756964 but never got around to it.

The only thing you might want to watch out for is the :visited state - the website shouldn't be able to tell whether a link is visited by looking at timing information (e.g. painting duration). The :visited pseudoclass is allowed to change the background-color property.
In the current state, if you have the following CSS rules:

.link { background-color: blue; }
.link:visited { background-color: purple; }
.link.make-blue { background-color: blue; }
.link.make-purple { background-color: purple; }

Now toggling the "make-blue" class on the element will always cause a repaint, regardless of whether the link is visited or not visited, even if the actual color on the screen isn't changing. And the same happens if you toggle the "make-purple" class. By always causing a repaint, the website won't be able to tell whether the link is visited or unvisited by looking at the paint duration.
If you generalize this testcase to include an animation, I'm worried that there might be a way of hitting an optimized path where we skip composites in the visited state but not in the unvisited state (or the other way round), and then the lack of composition might be observable by the website.

So this is worth thinking about, but it might not actually be a problem.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

Thank for the nice example, Markus.  That's indeed a problem.  It seems to me that we should stop background-color running on the compositor for :visited somehow.