W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2014

Re: Animation frame task

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 22 Aug 2014 11:10:42 +0200
Message-ID: <CADnb78i651q8Ok01AAvdEo81=26iPohOUS0Hok0zMt07LonK7Q@mail.gmail.com>
To: James Robinson <jamesr@google.com>
Cc: Elliott Sprehn <esprehn@gmail.com>, "www-dom@w3.org" <www-dom@w3.org>, "public-web-perf@w3.org" <public-web-perf@w3.org>, "www-style@w3.org" <www-style@w3.org>, Ian Hickson <ian@hixie.ch>, "public-fx@w3.org" <public-fx@w3.org>, Yehuda Katz <wycats@gmail.com>, Rafael Weinstein <rafaelw@google.com>, Adam Klein <adamk@google.com>, Adam Barth <w3c@adambarth.com>
On Fri, Aug 22, 2014 at 8:07 AM, James Robinson <jamesr@google.com> 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.

Received on Friday, 22 August 2014 09:11:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:23 UTC