Intent to Experiment: Animation Worklet
Majid Valipour
Contact emails
[email protected], [email protected]
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
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
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
--
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
LGTMI'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.
Majid Valipour
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
Majid Valipour
Philip Jägenstedt
--
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.
