W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: The need to re-subscribe to requestAnimationFrame

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 02 Mar 2013 09:10:53 -0500
Message-ID: <5132086D.9030807@mit.edu>
To: public-webapps@w3.org
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).

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC