Re: Animation frame task

On Thu, Aug 21, 2014 at 10:56 PM, Anne van Kesteren <annevk@annevk.nl>
wrote:

> On Fri, Aug 22, 2014 at 5:37 AM, Elliott Sprehn <esprehn@gmail.com> wrote:
> > Blink does FIFO on "animation frame events" and then processes
> > requestAnimationFrame callbacks after that. Currently we process scroll
> > events, media queries, resize events, and the overflowchanged event in
> the
> > FIFO queue. We plan to move more things there in the future (probably
> > everything you listed). I don't think we want an explicit ordering in the
> > queue, it should work just like the microtask queue with promises. Blink
> > also has a concept of a unique event, specifically it'll only ever fire
> one
> > scroll event per frame, even if there's many scrolls in that time period.
>
> What about mouseover and friends?
>
> I guess the best place to define this structure would be in HTML still
> as that currently defines the event loop as well as microtasks and
> such.
>

HTML defines the event loop and it defines (as much as anything does) when
the 'update the rendering' step happens, which is I think when all of this
should be tied to. Specifically I think we should extend Step 8 of the
processing model:

http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-9

8.) Update the rendering: If this event loop is a browsing context event
loop (as opposed to a worker event loop), then, if necessary, update the
rendering or user interface of anyDocument or browsing context to reflect
the current state.

To say something like:

To update the rendering, run these steps:
1.) Run tasks in the bag-of-stuff-to-run-before RAF in some order (probably
FIFO).  This includes the set of things Elliot mentioned (scroll updates,
media queries, etc etc) and anything else we want to put in other than the
requestAnimationFrame events themselves
2.) Run the 'Sample all animations' task:
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html#processingmodel
3.) Render the document to reflect the current state

I think it's important that rAF callbacks be the last script thing that
runs here so the author has a chance to get everything ship-shape before
rendering actually happens, else you get flashes and inconsistencies like
the ones in the test case Elliot demonstrated.  I'm not sure if we need the
step in (1) to be hookable by other specs or not but it might be useful.

If we want to define that to be FIFO then we have to strictly define when
items in that queue are added to the queue, which for things like media
queries and other CSS/layout-driven tasks might be hard.

- James

Received on Friday, 22 August 2014 06:08:17 UTC