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

On 12/7/11 1:57 AM, James Robinson wrote:
>     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".
>
>
> How is the concatenation done?  I would think the easiest thing to
> implement would be to do something like:
>
> for each document in "list of documents that have animation callbacks"
>    append all callbacks within document to global list

That's exactly what Gecko does.

> which would mean that all entries for a given document would be adjacent
> in the final, flattened list.

Yep.

> This agrees with what the spec currently
> says and it nearly agrees with what WebKit does today

Except in cases where new callbacks are requested across documents from 
other callbacks.

> except that WebKit assembles this list by documents in document order, not by
> document in registration of initial callbacks order.  This would be an
> observable different to some scripts so I think we should specify a
> behavior.

Hmm.  I agree that it would be observable, but I'd be fine with leaving 
inter-document order undefined (just like it is for setTimeout).

>   So a conforming UA could either choose to go ahead and paint at that
> point or not.  I believe the WebKit implementation today will not paint
> in that instance except for window.print() which is currently
> implemented in different ways in different WebKit embedders and probably
> has bugs in both.

Interesting.  I can confirm that, say, CSS transitions don't happen in 
WebKit while an alert is up.  They do in Gecko and Presto. Fun.

> I haven't put too much thought into this particular case in the spec or
> in the WebKit implementation because it's just to full of stupid.  I'd
> be happy saying that calling showModalDialog() during a rAF callback
> throws an exception and having that be the end of it.

I could live with that.  Not sure whether it should be in our spec here 
or in the showModalDialog spec...

>     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).
>
> I think it only makes a difference if a document changes its 'fully
> active' state, which should prevent any tasks for that document from
> happening and thus any callbacks for that document from firing.

Hmm.  We don't do any such thing right now, for what it's worth.  Once 
callbacks for a document tree start firing, they all fire in Gecko.

> I haven't experimented with this scenario much - I guess you could
> navigate a document with pending callbacks synchronously to about:blank

Not sure there's such a thing (per spec, at least).  Would removing a 
document's containing iframe from the DOM make it stop being "fully active"?

>     Yeah, I believe the spec pretty clearly requires atomic processing
>     for a single document (modulo the "blocking call" weirdness, of course).
>
> Do you think this is good or bad?

I think it's fine.

> 1.) Instead of queuing a task for each document, queue a task that runs
> over all documents and does the following:
>   a) Create an empty list of <handle, callback> tuples called L
>   b) For each document in DOM order
>    i) Copy all entries in that document's animation frame request list
> into L
>    ii) Clear that document's animation frame request list
>   c) For each entry in L
>    i) If that entry's callback's cancelled flag is not set, call the
> sample operation of that entry's callback and swallow any exception

This is basically what Gecko does, except the DOM order thing.

And also, it's not "all documents" in general; it's all documents under 
a given root browsing context or some such.

> 2.) Same as (1) except that in step (b) iterate over documents in the
> order that the first animation callback was registered in that document
> instead of in DOM order

This is exactly what Gecko does, I believe.  It's obviously simplest for 
me to do; the main drawback is that this order of callback registration 
is not really predictable for web developers.  Do we care?

> 3.) Callbacks are run in the order they are registered, regardless of
> which document they are registered in.

Let's not do that.  That gets very complicated very fast, I suspect.

> I believe that (1) is what I've attempted to implement in WebKit and (2)
> is what you are describing in Gecko.

Agreed on the latter.  For the former, the actual webkit implementation 
is observably different from (1) because the callback processing happens 
before you move on to the next document.

> (3) has some advantage of
> consistency, but I dislike it as it intermingles callbacks from
> different documents and potentially different domains.  I can't convince
> myself of any great reason to favor 1 or 2 over each other, and I
> suspect it won't be meaningful to too many authors, so let's just pick one.

The other option is leaving this part undefined for now....

-Boris

Received on Wednesday, 7 December 2011 07:23:06 UTC