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
