Re: requestAnimationFrame

On Mon, Nov 15, 2010 at 3:58 PM, Robert O'Callahan <>wrote:

> On Tue, Nov 16, 2010 at 12:03 PM, Gregg Tavares (wrk) <>wrote:
>> One is, how should this api be used if I want an app to update at 10hz.
>>  It seems to be designed to assume I want the maximum frame rate. If I want
>> to run slower would I just use
>> setInterval(function() {
>>    window.requestAnimationFrame();
>>   }, 100); // request frames at 10hz?
>> That's fine if that's the answer
> If you really want to animate in 10Hz steps, then I suggest you do
> something like
> var start = window.animationTime;
> var rate = 10; // Hz
> var duration = 10; // s
> var lastFrameNumber;
> function animate() {
>   var elapsed = window.animationTime - start;
>   if (elapsed < duration) {
>     window.requestAnimationFrame(animate);
>   }
>   var frameNumber = Math.round(elapsed/(1000/rate));
>   if (frameNumber == lastFrameNumber)
>     return;
>   lastFrameNumber = frameNumber;
>   // ... update the display based on frameNumber ...
> }
> window.requestAnimationFrame(animate);

That seems quite a bit more complicated than

   setInterval(myRenderFunction, 100);

Which is what you'd do today.

> (Out of curiosity, what are the use-cases for this?)

There is plenty of flash content that has a lower than 60hz (or fast as
possible) refresh rate. When something is instead implementing in HTML5
instead of Flash what should they do to get the similar results? Checking,,, and I found that 7
ads were set to run at 18hz, 3 were set to run at 24hz, 2 were set to run at
30hz. I used SWF
Info<>to check
the fps setting. I have no idea why they don't choose "run as fast
as possible." I could be laziness, it could be that it makes the pages too
slow and unresponsive to set them to "as fast as possible", it could be that
rendering 3 times more then necessary, 60hz vs 18hz would eat battery
life, it could be an artistic choice, it could be just that flash makes you
pick one vs defaulting to "fast as possible".

> That seems to have 2 issues.
>> 1) All of them will get a beforePaint event even if most or all of them
>> are scrolled off the visible area since there is only 1 beforePaint event
>> attached to the window.
> Something could be done here, but it seems rather complex to specify things
> in a way that avoids firing callbacks when relevant content is "out of
> view".
> 2) All of them will get beforePaint events at the speed of the fastest one.
>> If one ad only needs to update at 5hz and other updates at 60hz both will
>> update at 60hz.
> The above approach solves this I think.
> Rob
> --
> "Now the Bereans were of more noble character than the Thessalonians, for
> they received the message with great eagerness and examined the Scriptures
> every day to see if what Paul said was true." [Acts 17:11]

Received on Tuesday, 16 November 2010 00:27:22 UTC