Re: requestAnimationFrame

On 11/16/10 1:52 PM, Gregg Tavares (wrk) 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?

I'll let roc talk about how he sees this working in the future, and in 
particular about your compositor thread question below, but in the 
current Gecko model, this is correct.  The content area will not paint 
updates, change layout, etc, until the JS returns.

Note that in your resize scenario I would in fact not expect the layout 
to change under a script while the script is running, so the browser 
couldn't relayout to the new size until the JS returns anyway.

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

The guarantees we currently supply are:

1)  Your requestAnimationFrame handler will be called before painting.
2)  The handler is passed an argument (directly, if you used a function
     callback; as event.timeStamp if you used an event handler) that
     indicates the time that was or will be used to sample SMIL
     animations and CSS Transitions that will paint when the paint
     happens.  This may be different from the current time, depending
     on what other animation frame handlers are involved and how long
     they take.

Now your script knows the time that it's "painting at" wrt animations, 
and can compute the proper thing to be showing to be in sync with them.

-Boris

Received on Tuesday, 16 November 2010 19:28:27 UTC