- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 13 May 2013 23:58:10 -0400
- To: whatwg@lists.whatwg.org
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
Received on Tuesday, 14 May 2013 03:58:55 UTC