Intent to Experiment: Animation Worklet

[Majid Valipour]

Contact emails

maj...@chromium.org, fla...@chromium.org

Spec

https://wicg.github.io/animation-worklet/

Summary

The Animation Worklet API enables a new class of script-driven and statefull animations within Web Animation’s ecosystem. Furthermore it allows such animations to run in parallel worklet execution contexts thus providing performance isolation from the main thread. ScrollTimeline is a new type of animation timeline that allows animations to be linked to scroll offset of another element. We believe combined, these primitives enable high performance scroll-linked and procedural animations on the web.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/7CiC3CaPHek/Cy0CN0R6AwAJ

Goals for experimentation

Our goal is to validate that the API provides sufficient functionality to address developers needs in practice. The API was made more restrictive to better fit the web animations model and we like to ensure it is still powerful enough for its intended usage.

Also we intend to get feedback on potential improvements in user experience, particularly animation smoothness and page interactivity. During the experiment, we plan to monitor specific metrics related to frame rate, responsiveness, memory usage, and Javascript execution time on the animation worklet thread to better understand associated costs and improvements in real world scenarios.

Experimental timeline

We like to run the experiment for two milestones. Below is the timeline for Stable channel:

Enabled: Chrome 66 Stable - April 17th, 2018 **

Disabled: Chrome 68 Stable - July 24th, 2018

** Dates are estimates from https://www.chromium.org/developers/calendar

Any risks when the experiment finishes?

The developers will lose access to the API but given that they can detect the feature availability, we expect them to fallback to the existing methods for providing the same effects (mainly relying on window.requestAnimationFrame on main thread).

Reason this experiment is being extended

N/A

Ongoing technical constraints

None

Debuggability

Devtools is already able to show threaded worklets in sources panel and it supports adding breakpoints for scripts running in worklet thread.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5762982487261184

[Rick Byers]

LGTM

I'm really excited to hear how this performs in practice!  Any chance we can get UMA comparing worklet smoothness metrics with main thread smoothness (i.e. what a dev could achieve with RAF today)?  Being able to say "X% fewer dropped frames in the wild on real Android devices" could be valuable data in weighing the cost/benefit tradeoff.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB8RdXsf7kYpais9nMoG9s_h_fKA-M5FbQUzGZqEReJ-DcrDgw%40mail.gmail.com.

[Majid Valipour]

On Tue, Feb 13, 2018 at 6:09 PM Rick Byers <rby...@google.com> wrote:

LGTM

I'm really excited to hear how this performs in practice!  Any chance we can get UMA comparing worklet smoothness metrics with main thread smoothness (i.e. what a dev could achieve with RAF today)?  Being able to say "X% fewer dropped frames in the wild on real Android devices" could be valuable data in weighing the cost/benefit tradeoff.

We were actually thinking about doing something like this and I was discussing with origin trial experts to see if it is possible to combine and origin trial with a finch experiment to enable A/B testing based on UMA metrics. Here is a small doc (internal only) I put together about the metrics we plan to monitor.

Majid

 

[Majid Valipour]

We didn't start the origin trial on our originally planned milestone. The decision was made based on early feedback we received. Since then we have focused on fixing issues, improving performance, and enabling support for animating all properties.

We are now ready to start the trial and here is the proposed new timeline.

Experimental timeline

We will run the experiment for two milestones. Timeline for Stable channel:

Enabled: Chrome 71 Stable - Dec 4th, 2018

Disabled: Chrome 73 Stable

A blog post with more detail on usage and how to sign up will be published shortly.

Thanks,

Majid

[Majid Valipour]

I like to extend this experiment until M75 stable. 

We have been collaborating with AMP animation team to re-implement their scrollbound animations system to use AnimationWorklet+ScrollTimeline.

Their usage has been providing us with valuable feedback. I will soon be sharing a summary of our findings so far but in particular we will be proposing specific changes to ScrollTimeline API to improve its ergonomics. While we are reworking ScrollTimeline APIs, I like to continue this trial with current API with the aim of learning more in particular about Animation Worklet performance at scale.

Majid

[Philip Jägenstedt]

LGTM to continue experimenting

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB8RdXtxjtHK5VjVd4fZbH4c%2BHekKP9wC_XXgf0dLUxd23JDbA%40mail.gmail.com.

[malikabenab...@gmail.com]

[Majid Valipour]

Thanks Philip!

Here is the summary of our leanings from this origin trial so far. We have already opened issues in the upstream specification (e.g., 1, 2) to suggests changes based on this.

Majid