RE: Animation frame task

I'm slow, so forgive the questions.

The way I understand what you're asking is that you want all of the events that the UA fires before RAF to be extensible. So, on a frame, you propose that we:

1) Execute coalesced browser events (screen orientation, scrolling, mouse movement, gamepad presses, etc)
2) Execute user-defined events
3) Execute requestAnimationFrame callbacks

Is that correct? If not, could you give me a scenario?

If so, could you help me understand why you can't do this today? The guidance I understand is that you update a model on browser-related events (1), and on rAF callback, you can update the DOM based on the model before executing the rest of your callback. That gives you complete control over (2) and (3) above.

A scenario would help me understand what you're recommending.

Thanks in advance for helping me understand this.

Tobin

-----Original Message-----
From: annevankesteren@gmail.com [mailto:annevankesteren@gmail.com] On Behalf Of Anne van Kesteren
Sent: Monday, August 25, 2014 2:36 AM
To: James Robinson
Cc: www-dom@w3.org; public-web-perf@w3.org; www-style@w3.org; Ian Hickson; public-fx@w3.org; Mounir Lamouri
Subject: Re: Animation frame task

On Fri, Aug 22, 2014 at 8:07 AM, James Robinson <jamesr@google.com> wrote:
> 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

This might be problematic for things that tie into each other. E.g.
screen orientation wants to do things after fullscreen changes in one way or another as I understand it. Not sure how that would work with FIFO, though I guess screen orientation and fullscreen could just have tight coupling.


--
http://annevankesteren.nl/

Received on Monday, 25 August 2014 23:27:15 UTC