Re: JavaScript-Driven Accelerated Animations

On Wed, Oct 2, 2013 at 11:28 AM, Ian Vollick <vollick@chromium.org> wrote:
> Hi All,
>
> I've been informally discussing an idea that would allow JavaScript to drive
> animations of certain CSS properties from a web worker thread. I've put
> together a high level explainer for the idea here:
> https://github.com/ianvollick/animation-proxy/blob/master/Explainer.md
>
> If you have a moment, please take a look and let me know what you think.
>
> Here's a snippet from the doc:
>
> JavaScript-driven animations are extremely flexible and powerful, but are
> subject to main thread jank (by jank, I mean unpredictable interruptions in
> the rate that animations are serviced on a thread due to other, unrelated
> work on that thread). And although JavaScript can run on a web worker, DOM
> access and CSS property animations are not permitted. Despite their
> susceptibility to main thread jank, main thread animations are widely used;
> they're the only way to create common effects such as parallax,
> position-sticky, image carousels, custom scroll animations, iphone-style
> contact lists, and physics-based animations. In a perfect world, the main
> thread would always be responsive enough to guarantee that a JavaScript
> animation callback would be serviced every frame. In reality, this is
> extremely hard to achieve, both for user agents and developers of large
> sites composed of disparate components. The result is a lot of janky pages.
>
> Why can't we update CSS properties from a worker thread? Updating CSS
> properties could effect a style recalc or a layout and those operations must
> happen on the main thread. That said, there are certain 'layout-free'
> properties that can be modified without these side effects. These properties
> include transform, opacity and scroll offset. Clearly identifying these
> layout-free properties and allowing them to be animated from any thread
> would provide a simple and powerful way to achieve smooth animations.

I strongly support this.  Dean recently said that the WebKit team had
come around to my earlier idea of Scroll-Driven Animations, and this
idea from Ian is basically an explanation of that idea.

In other words, while I want to pursue Scroll-Driven Animations or
something very close to it, to make a lot of common effects very easy,
it will always be somewhat constrained to what we implementors
*decide* to expose.  Ian's idea here lets authors do *anything* they
want, at only a tiny cost over doing it within the bounds of what we
expose with SDA.

~TJ

Received on Wednesday, 2 October 2013 21:19:27 UTC