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/