W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: requestAnimationFrame

From: James Robinson <jamesr@google.com>
Date: Wed, 17 Nov 2010 18:48:32 -0800
Message-ID: <AANLkTik-x=qAaiiU3t=NndgjHD2PcoDLa4fHGbHcohyr@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "Gregg Tavares (wrk)" <gman@google.com>, robert@ocallahan.org, "public-webapps@w3.org" <public-webapps@w3.org>
On Wed, Nov 17, 2010 at 6:27 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 11/17/10 5:22 PM, Gregg Tavares (wrk) wrote:
>
>> Think about this some more..... the point if the previous suggestion is
>> that updating keeping a JS animation in sync with a CSS animation has
>> nothing to do with "painting" or rendering. The fact that apparently
>> firefox ties those 2 things together is an artifact of firefox's
>> implementation.
>>
>
> Oh, I see the issue.  The event name.
>
> The name was just picked as a way of telling script authors something about
> what the callback means.... All that Gecko promises right now is that you
> get the callback, then SMIL and Transitions and any pending style changes
> (including the ones your just caused) are processed and the layout/style of
> the page updated.
>
> Painting is in fact completely decoupled from this process in Gecko at the
> moment, except insofar as they happen on the same thread.  Nothing
> guarantees that you won't get another MozBeforePaint event before painting
> actually happens, or that you won't get multiple paints in a row without a
> MozBeforePaint event in between.  So yeah, the event name is somewhat
> suboptimal.  ;)
>
> Again, all the event means is "we're about to resample declarative
> animations; this is your chance to do script stuff that's supposed to look
> like an animation".
>

In Safari (and at some point in Chrome as well) declarative animations are
not necessarily sampled in the main thread.  In fact, during an animation
the main thread could be completely idle or completely busy running some
piece of long-running javascript.  If the computed styles on an animating
element are queried a value is interpolated from the main
thread independently of the animation itself.  It wouldn't be possible to
fire an event like this without adding additional synchronization between
the two threads which would make the animation less smooth.  I'm not
entirely convinced about how important it is to synchronize declarative and
script-driven animations versus making declarative animations work really
well.

- James


> -Boris
>
>
Received on Thursday, 18 November 2010 02:49:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT