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

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

Received on Tuesday, 14 May 2013 03:33:21 UTC