[whatwg] A better animation API

Nicholas C. Zakas standards at nczconsulting.com
Mon Dec 12 18:07:07 PST 2011

I'd like to +1 the suggestion for a continuous animation loop, though if 
I remember correctly I think the concern about such an API was that it 
would lead to forgotten animations that would keep going long past they 

I'd much rather have an API to start and stop animations, but I'm not 
sure if the developer convenience outweighs the potential downside of 
forgotten, long-running paint requests.


On 12/10/2011 12:13 AM, Boris Zbarsky wrote:
> On 12/10/11 3:11 AM, Boris Zbarsky wrote:
>> On 12/10/11 2:55 AM, Robert Eisele wrote:
>>> It's certainly also more difficult to implement but asking for every
>>> frame
>>> to continue has also the disadvantage of beeing as slow as setting up
>>> a new
>>> timeout for every frame. That's why setInterval surpass setTimeout's
>>> performance (okay, at least it should).
>> In theory, yes.
> One other note.
> The principal practical difference between setInterval and setTimeout 
> (other than all the pages that setInterval something and then forget 
> to cancel it) is their handling of delays in firing times.  With 
> setInterval you can get a more uniformly firing timer, because if one 
> firing gets delayed the next one might compensate.  With setTimeout 
> the only way to get that behavior is to manually compensate by 
> comparing the actual firing time to the desired one and adjusting the 
> argument to the next setTimeout call accordingly.
> With requestAnimationFrame, of course, the firing time thing is a 
> non-issue, because you're not scheduling a callback for a particular 
> time in the first place.
> -Boris

Nicholas C. Zakas

More information about the whatwg mailing list