Re: requestAnimationFrame

On Wed, Nov 17, 2010 at 7:52 AM, Gregg Tavares (wrk) <gman@google.com>wrote:

> So if the JS on the beforePaint takes a while to complete what happens to
> the browser? For example if you are resizing the browser? Is the browser
> forced not to be able to actually paint until JS returns?


Not necessarily. In Firefox 4, yes. In Mobile Firefox, which supports
compositing in a separate process from the content, no.


>
>
>> Now, when animation is happening on a separate compositor thread that
>> guarantee has to be relaxed a bit. But we'll still try to meet it on a
>> best-effort basis --- i.e. "we'll run the JS animations once per composited
>> frame, if the JS can keep up".
>>
>
> So you're saying that there's no guarantee that requestAnimationFrame will
> actually keep things in sync?
>

Right. A cast-iron guarantee that requestAnimationFrame callbacks will run
to completion before painting is incompatible with the goal of being able to
repaint the browser window even if scripts are running too long or
completely hung.

But we *can* guarantee that a) scripted animations stay in sync with each
other, and b) if the HTML5 event loop is not too busy (e.g., animation
scripts take much less time to complete than the interval between composited
frames and the content process is otherwise idle), scripted animations will
stay in sync with with declarative animations even if the declarative
animations are being processed by an off-main-thread compositing framework.
(OK, this is a bit speculative since we haven't implemented it yet, but the
approach seems straightforward.)

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]