- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 15 Nov 2010 16:10:44 -0800
- To: robert@ocallahan.org
- Cc: "Gregg Tavares (wrk)" <gman@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Mon, Nov 15, 2010 at 3:58 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Tue, Nov 16, 2010 at 12:03 PM, Gregg Tavares (wrk) <gman@google.com>
> 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);
>
> (Out of curiosity, what are the use-cases for this?)
*If* this is a use case that is important enough to solve, then one
solution would be to allow a interval to be passed to
requestAnimationFrame when a callback is specified. When such an
interval is passed, the implementation would call the callback no
sooner than the requested interval.
Though one concern would be that people might depend on the callback
being called exactly then, and not take into account the fact that the
callback rate might be significantly slower if for example the page is
in a background tab.
/ Jonas
Received on Tuesday, 16 November 2010 00:13:38 UTC