Re: JavaScript-Driven Accelerated Animations

On Wed, Oct 2, 2013 at 2:15 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/2/13 2:28 PM, Ian Vollick wrote:
>>     CSS properties could effect a style recalc or a layout and those
>>     operations must happen on the main thread.
>
> Those happen async anyway, so aren't a problem per se if we're not worried
> about a background thread touching the CSSOM.
>
> That said, reading your proposal it sounds like you're basically proposing
> sugar for computing the values of properties in a worker but then actually
> setting them on the main thread, right?  At least that's my best guess for
> what the asynchronous proxies are meant to do?

Ian can explain it better, but to best of my knowledge, not quite.
The handful of properties that are exposed to an Animation Proxy are
precisely those that can be done by the compositor.  The idea here is
that the compositor gets first crack at the values, eagerly applying
them, then the value trickles down into the main thread and does a
property set at the appropriate time.  If that ends up meaning that
the compositor was a bit overeager, and the actual value ends up being
something else, so be it, that's just a frame or two incorrect and can
be easily recovered from. I believe we, at least, already deal with
this kind of prediction in some cases (again, Ian can explain more),
and so exposing it more broadly won't be a problem for us.

In other words, as far as JS can see, yes, it's just sugar for setting
them on the main thread.  As far as the *user* can see, though, it's
faster and more response JS-driven animations for a handful of
properties.  This means that in some cases the JS will be lying for a
short while about what the user-seen value is.

~TJ

Received on Wednesday, 2 October 2013 21:23:23 UTC