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

[Kyle Simpson]

I'm proposing a couple of companion APIs to the already standardized 
`requestAnimationFrame(..)` API.


First: https://gist.github.com/getify/5130304

`requestEachAnimationFrame(..)` and `cancelEachAnimationFrame(..)`

This is the analog to `setInterval(..)`, in that it runs the handler 
automatically for every animation-frame, instead of requiring you to re-queue 
your function each time. Hopefully that could be made slightly more performant 
than the manual re-attachment, and since this is often a very tight loop where 
performance really does matter, that could be useful.

It will make animation loops, frame-rate detection, and other such things, a 
little easier, and possibly slightly more performant. The code linked above has 
the polyfill (aka prollyfill aka hopefull-fill) logic.


--


Second: https://gist.github.com/getify/3004342#file-naf-js

`requestNextAnimationFrame(..)` and `cancelNextAnimationFrame(..)`

`requestNextAnimationFrame(..)` queues up a function not for the current 
upcoming animation-frame, but for the next one. It can be accomplished by 
nesting one rAF call inside another, as the polyfill implies, but again, my 
presumption is that this sort of logic is not only more awkward but also 
possibly slightly less efficient than if it were built-in as I'm proposing.

Why would we need this? Well, there are some sorts of CSS-based tasks which end 
up getting automatically batched-together if they happen to be processed in the 
same rendering pass. 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, and the repaint will show the element at its 
final location. Bummer. So, I have to first unhide it in the current 
animation-frame, and then add the class for the transition to the *next* 
animation-frame.

Do that kind of thing enough times (which I have), and you start wishing there 
was a codified API for it, instead of my hack. Thus, my simple proposal here.




--Kyle

Re: [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