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
