[whatwg] Proposing: some companions to `requestAnimationFrame(..)`

[Boris Zbarsky]

On 5/13/13 11:32 PM, Kyle Simpson wrote:
> First: https://gist.github.com/getify/5130304
>
> `requestEachAnimationFrame(..)` and `cancelEachAnimationFrame(..)`
>
> This is the analog to `setInterval(..)`

which was explicitly considered and rejected when requestAnimationFrame 
was designed, based on past experience with people setting intervals and 
never clearing them.

> Hopefully that could be made slightly more performant than the manual re-attachment

It's worth quantifying the performance impact of having to make a 
requestAnimationCall.  Have you?

For what it's worth, I have; it's around 1us in the slowest browser 
implementations I could find (which are working on making it faster, 
too), and typically happens once per frame.

> It will make animation loops, frame-rate detection, and other such things, a little easier

It will also make forgetting to stop them a _lot_ easier, which is 
somewhat unfortunate.

> For example: if you want to unhide an element (by setting display:block) and then tell the element to move via a CSS transition (say by adding a class to it). If you do both those tasks in the same rendering pass, then the transition won't occur

If you do them across two different animation frames it may still not 
occur.  Nothing in the transitions spec requires it to, and I would not 
be surprised if current or future UAs in fact throttle style updates to 
"not every animation frame" in some cases.

Instead of adding APIs for this hack around the fact that transition 
starts are not really defined, we should probably just get Web Animation 
closer to done and get people who want effects like this to use it 
instead of transitions.

-boris