- From: Nicholas C. Zakas <standards@nczconsulting.com>
- Date: Mon, 12 Dec 2011 18:07:07 -0800
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 should. 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. -N 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 http://www.nczonline.net
Received on Monday, 12 December 2011 18:07:07 UTC