[css-animationworklet] Experiment with different sync models for animations with mixed accelerated and non-accelerated properties

[majido]

From @RByers on September 22, 2016 13:15

Some (eg. @birtles) have argued that we should be consistent with animations on the web and allow any property as an output property. Eg. to avoid requiring a spec change to expand the set of animatable properties (since some browsers may move faster on that than others).

I think there's broad support for expanding the design for that, though there is debate over how exactly that should behave.

In particular, by default we'd like an error delivered to window.onerror by default whenever a not accelerated property is animated (indicating that animation can only be performed at the rate of the main thread). Optionally a developer can indicate that they are OK with main-thread animations and disable this warning (perhaps a 3rd setting for the option in #1).

Also there is significant debate over what should happen when an Animator changes an accelerated property of one element as well as a non-accelerated property of another element. There are two main options:

1. Synchronized: all elements update at the rate of rAF
2. Unsynchronized: the elements where only accelerated properties are changed will update off-thread, while other elements will update at least a frame behind.

Proposal: have an option for now to support either mode and build concrete demos which are better in one mode over the other. We can pull the mode switch from the v1 API if no critical use cases end up requiring one of the modes.

Copied from original issue: WICG/animation-worklet#2

[majido]

The spec now supports animating all properties. The remaining question is how to deal with effects that mix an accelerated property with non-accelerated property which can be updated at different frame rates. I am going to update the issue title to reflect this.

Most current implementations seems to do option 1 which means the resulting updates run in sync but at the cost of running at lowest update rate.

[birtles]

Most current implementations seems to do option 1 which means the resulting updates run in sync but at the cost of running at lowest update rate.

Gecko differentiates between different types of properties. If you are animating two geometric properties--e.g. 'width' and 'transform'--with the same animation (or even in different animations but with the same starting time) and one can't be run on the compositor, we run both of them on the main thread.

If you're animating background-color and transform, however, we'll happily do background-color on the main thread and transform on the compositor.

[majido]

Gecko differentiates between different types of properties. If you are animating two geometric properties--e.g. 'width' and 'transform'--with the same animation (or even in different animations but with the same starting time) and one can't be run on the compositor, we run both of them on the main thread.
If you're animating background-color and transform, however, we'll happily do background-color on the main thread and transform on the compositor.

This is great. I made a small demo that showcases this. In Firefox only background janks but in Chrome both background and transform jank. The fact that Firefox has shipped this already is a good sign that we should follow.

@flackr has previously advocated that we should even go further and allow unsynchronized updates for all properties (demo). @birtles can you share the thinking behind why Gecko have chosen to always keep geometric properties in sync?

[birtles]

@birtles can you share the thinking behind why Gecko have chosen to always keep geometric properties in sync?

The original implementation where we decided to synchronize geometric properties within an element predates my involvement in compositor animations so there may have been technical limitations, but for synchronizing across elements I know one site that motivated that was trello.com.

Specifically, trello.com triggers transitions on margin-right and transform at the same time. We would previously do the transform animation on the compositor and margin-right animation on the main thread and they would get out of sync and look awkward so we added a mechanism to detect if we have these geometric animations/transitions (or, I suppose "layout" animations/transitions) triggered at the same time, and, if we can't run them all on the compositor we run them all on the main thread so they stay in sync.

Details are in Mozilla bug 1301305.