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

Re: requestAnimationFrame

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 17 Nov 2010 21:27:06 -0500
Message-ID: <4CE48EFA.4030806@mit.edu>
To: "Gregg Tavares (wrk)" <gman@google.com>
CC: robert@ocallahan.org, "public-webapps@w3.org" <public-webapps@w3.org>
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".

-Boris
Received on Thursday, 18 November 2010 02:27:43 GMT

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