It seems like it could.

Okay, though this may not be an answer what Jeff expected, and I might have tested on a different site (https://browserbench.org/MotionMark/developer.html) what Jeff looked at.

If the original question is "why isn't Firefox able to run 'Leaves' or 'Multiply' animations on the compositor?", then the answer is because it's driven by requestAnimationFrame callbacks and it changes transform and opacity styles on every frame.

If the original question is "why does MotionMark use requestAnimationFrame? why wasn't it implemented by CSS animations?", then my best guess is that at that time Webkit implemented it they didn't have enough CSSOM supports to generate @keyframe rules in JS? Nowadays all major browsers support majority parts of Web Animations APIs so that it can be easily implemented as animations runnable on the compositor. It looks to me it's feasible. Indeed, 'Leaves' just changes transform and opacity styles, and 'Multiply' changes transform and background-color styles so that it can be run on the compositor on both of Firefox and Chrome (I don't know Safari can run background-color animations on the compositor). And I agree if the MotionMark's purpose is doing benchmarks for graphics performances and less involving JS, then it should use Web Animations APIs or CSS animations.

The original question was "why isn't Firefox able to run 'Leaves' or 'Multiply' animations on the compositor?". But I've realized that wasn't actually what I wanted to ask.

The actual question, for which you may not have the answer, is: could we run requestAnimationFrame driven animations without needing to build the Gecko and webrender display lists. Instead, just send the property changes to the compositor.

That's a very interesting question. Yeah, it sounds it's feasible theoretically as you imagined.

1. we can detect style changes that it can be run on the compositor if it's changed by CSS animations
2. then we can skip restyling for the style changes
3. and then it can be propagated into the corresponding webrender display items directly (by adding a new route to do it)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)

1. we can detect style changes that it can be run on the compositor if it's changed by CSS animations

The detection should be done in nsDOMCSSAttributeDeclaration::MutationClosureFunction by checking nsDOMCSSAttributeDeclaration::MutationClosureFunction

2. then we can skip restyling for the style changes

A relevant part is here in RestyleManager::AttributeChanged, we need to skip calling Servo_NoteExplicitHints.

3. and then it can be propagated into the corresponding webrender display items directly (by adding a new route to do it)

I believe gfx people is more familiar with this part.

Of course there will be more involving stuff something like in this case we shouldn't apply this optimization or we should forcibly flush the style changes, etc. etc.