Re: Animation frame task

Anne van Kesteren <[email protected]>
Newsgroups gmane.comp.web.dom.general,gmane.org.w3c.webperf,gmane.comp.web.css.general
Message-ID <CADnb78gXakZsOaYKjba8mFVwZsjWbRy05=P2GS4SzGR39DQf7A@mail.gmail.com>
On Fri, Aug 22, 2014 at 5:37 AM, Elliott Sprehn <[email protected]> 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.


> I also think there's value in spec'ing how RAF interacts with rendering,
> since it seems browsers disagree a lot there. An example is
> http://jsfiddle.net/vk2x5tL1/show/ Here setInterval and RAF are setting two
> different colors. In Blink RAF always wins, because we layout and paint
> immediately after RAF. In Firefox which one wins seems to be totally
> arbitrary, you can refresh repeatedly and get stuck with a different color
> each time. In Safari and IE it will flicker constantly between the two
> colors.


-- 
http://annevankesteren.nl/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.