Re: JavaScript-Driven Accelerated Animations

On Wed, Oct 2, 2013 at 5:22 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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.
>

Tab's got it right here. What I think I did a bad job of explaining is that
the proxy is meant to allow a direct line of communication from a worker to
the compositor, skipping the main thread and its unpredictability. The only
properties that may be affected by a proxy are those that can be handled
entirely by the compositor. The interactions between the compositor and
worker thread will, of course, be asynchronous since we cannot hold up the
compositor. The values sent to the compositor will eventually need to make
their way to the main thread as they do with threaded scrolling.

(Note: due to the asynchronous nature of the API it's definitely possible
that the proxied element may have disappeared by the time the compositor
gets around to processing the updates from the worker. That should be
simple to handle if the getters and setters return promises.)