Re: Animation frame task

On Fri, Aug 22, 2014 at 8:07 AM, James Robinson <[email protected]> wrote:
> 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.

Yes we should make that extensible.


> 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.

This will end up being required I think. The more we make this
extensible, the more observable and painful it will get for developers
if we do not fix this.

I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26636 on HTML
pointing to your email as a start towards fixing this.


-- 
http://annevankesteren.nl/