Re: [RequestAnimationFrame] Processing model does not permit handling animation callbacks for multiple documents at once

On 12/7/11 12:56 AM, James Robinson wrote:
> On Tue, Dec 6, 2011 at 8:18 PM, Boris Zbarsky <bzbarsky@mit.edu
> <mailto:bzbarsky@mit.edu>> wrote:
>
>     In at least Gecko's implementation, all documents in a given tab are
>     treated in an atomic manner for purposes of animation callbacks, in
>     the sense that all the callbacks from all those lists are placed
>     into a single list, then all the document-level lists are cleared,
>     and then the callbacks are processed.
>
>
> In what order are callbacks from different documents processed?

In Gecko?  When the first entry is added to a document's list of 
animation callbacks, that document is itself added to a list of 
documents that have animation callbacks.

Then when it comes time to call the callbacks the lists of animation 
callbacks for those documents are just concatenated, with the ordering 
on lists matching the order of the "list of documents that have 
animation callbacks".

So in other words, there is no particular attempt to impose any sort of 
ordering other than whatever was simple to implement.

> Et voila.  Since the UA controls exactly when tasks are entered into the
> "animation task source" task queue, and the UA can decide when to
> service that task queue relative to other task queues like timers, etc,
> UAs actually have a lot of freedom here.

So what happens in practice when one of the callbacks does a sync XHR or 
puts up an alert?  Both in terms of what implementations actually do and 
in terms of what the spec currently requires, if anything?

> In practice what WebKit does is prior to painting it iterates through
> documents in DOM tree order and processes all the callbacks for that
> document.

OK, so this would correspond, in Gecko's case, to processing all the 
callbacks for one document before moving to the next one in the list 
(instead of concatenating all the lists then processing callbacks).

What does IE do here?

> One consequence of this model is that all callbacks for a given document
> must be processed as an atomic block - they cannot be interspersed with
> callbacks from a different document.

This is the case in Gecko too.

> This behavior somwhat falls out of the WebKit
> implementation details "for free" so I didn't put a ton of thought into
> making this clear in the spec text, although I believe it is there.

Yeah, I believe the spec pretty clearly requires atomic processing for a 
single document (modulo the "blocking call" weirdness, of course).

-Boris

Received on Wednesday, 7 December 2011 06:05:37 UTC