Re: The need to re-subscribe to requestAnimationFrame

On 3/2/13 6:03 AM, David Bruant wrote:
> I was wondering why it was the case. Other event-like mechanism do not
> require to re-subscribe after an event happened.

requestAnimationFrame was designed as a way for web pages to do 
animations without hogging CPU like they did with setTimeout/setInterval.

The obvious choices for the behavior were a setTimeout-like behavior or 
a setInterval-like behavior.

The former was chosen because the failure mode is that the animation 
stops when it shouldn't (which the author will notice and fix).  The 
failure mode for the setInterval-like behavior is that the page keeps 
hogging CPU doing useless work once the animation has finished, which 
most authors do not notice, based on experience with setInterval.

So of the two choices, the current behavior was a better fit for the 
goals of requestAnimationFrame.

Note also that this is not an "event-like" mechanism necessarily; the 
request _causes_ the callbacks to fire.  It also has other side-effects 
(for example, on Windows it switches the OS to high-resolution timers in 
many cases, increasing CPU usage and power consumption while there are 
live requestAnimationFrame listeners).

-Boris

Received on Saturday, 2 March 2013 14:11:21 UTC