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

On Tue, Dec 6, 2011 at 8:18 PM, Boris Zbarsky <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? (more on
this below)

>
> This is generally desirable (just like compositing them all at once is
> desirable) because otherwise you can get tearing when translucent iframes
> update animations at a different time from the main document.
>

Strongly agree.  This is what WebKit does as well.

>
> Unfortunately, the processing model does not seem to allow this.  It's not
> even clear to me whether it allows calling animation callbacks for multiple
> documents one after the other from the same task (which is something we
> could do in Gecko that would still prevent the tearing issue but be closer
> to the processing model as the spec defines it now, in that one document's
> callback list would not be cleared until another's were done processing).
>

My reading of the HTML processing model:
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-2is
that a conforming UA could update animations from different documents
by
behaving as if it acted in the following way:


1.) Perform the "queue <http://whatwg.org/html#queue-a-task> a
task<http://whatwg.org/html#concept-task>
 that samples all
animations<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html#dfn-sample-all-animations>"
from
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html#processingmodelfor
each document in the tab.
2.) Execute step 1 of the HTML processing model "Run the oldest
task<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task>
on
one of the event
loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>
's task queues<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-queue>,
ignoring tasks whose associated
Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document>s
are not fully active<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#fully-active>.
The user agent may pick any task
queue<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-queue>
." from
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-2
 choosing the "animation task source" task queue. This will update all
animations for one document.
3.) Execute steps 2-4 of the HTML processing model (they usually won't be
relevant)
4.) Choose *not* to update the rendering or user interface when executing
step 5 of the HTML processing model.  I'm assuming here that the "if
necessary" clause here gives UAs sufficient license to make this decision
5.) If the "animation task source" task queue is not empty, return to step 2
6.) Execute step 5 of the HTML processing model and actually update the
rendering.


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.

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.  It doesn't actually create tasks or anything like that, but I
believe that behavior is indistinguishable from the steps I described above
and thus is a valid optimization.

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.  I don't think this is an issue,
although it's not clear to me from your email whether this is what Gecko
does today or not.  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.  I
welcome any suggestions for how to make this clearer.

- James




> Thoughts?
>
> -Boris
>
>