W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: requestAnimationFrame

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 19 Nov 2010 10:54:48 +1300
Message-ID: <AANLkTi=BpGweZedDLnaFsMvBzTnp8N5neyi2_ZURZewO@mail.gmail.com>
To: Darin Fisher <darin@chromium.org>
Cc: "Gregg Tavares (wrk)" <gman@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>
On Fri, Nov 19, 2010 at 10:48 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Nov 19, 2010 at 10:46 AM, Darin Fisher <darin@chromium.org> wrote:
>> I agree.  What's the use case for animating hidden tabs (or canvases that
>> are hidden)?
>> One of the big problems with JavaScript based animations is that they have
>> no way of knowing they should "go idle" when their window is hidden (in a
>> background tab or otherwise).  The same API used to rate-limit rendering
>> could address the problem of hidden tabs too.
> Yes. As I mentioned, we do that in Firefox. Please read what I wrote above.

Hmm, maybe I didn't mention it in this thread yet, sorry.

I did mention the reason we want to guarantee the callback eventually fires:
apps often want to do something when an animation ends. Having to write a
special code path specifically to handle the case where an animation ends
but the tab/element is hidden sounds to me like it's going to be

"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 Thursday, 18 November 2010 21:55:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:28 UTC