The macOS fullscreen toolbar slide-down animation is currently rather sluggish, see bug 1701929.

It's just a translation, so it should be implementable very efficiently. However, at the moment, the following happens:

• The offset update notification from macOS arrives.
• JavaScript code tweaks inline style on the toolbox, updating the CSS transform property.
• The main thread of the parent process builds a new Gecko display list.
• The display list is converted to a WR display list and submitted to the compositor.
• WR gets the new display list and runs scene building on the entire window contents. This takes longer if there's more complex tab content.
• WR does frame building.
• WR does rendering.

It would be great if we could somehow avoid incurring a cost that scales with the complexity of the tab contents. It also scales with the number of tabs visible in the tab bar.

I think there's probably two mostly independent things we can do here to make this much better.

(1) On the Gecko side, change the way this is handled in the parent process to use (APZ-style) property animation. This would mean no need to rebuild the parent display list, and no need for WR to do a new scene build, in this case. I'm not sure of how easy this is to achieve, but it seems like it'd be useful for other things that occur in the parent display list too?

(2) Change WR to only traverse parent display list during scene and frame building, if the content display list(s) and APZ bindings haven't changed (I've been wanting to do this for a while - I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1720555 with some basic details).

Thanks!

(1) sounds doable but hard, if we want to implemented it for the generic .style.transform = ... case. Maybe it would be easier with a special privileged JS API... but then it would be a lot of complexity for a very small use case.

I'm very much looking forward to (2)!