Re: requestAnimationFrame

On Fri, Nov 19, 2010 at 8:21 AM, Gregg Tavares (wrk) <>wrote:

> On Thu, Nov 18, 2010 at 12:45 AM, Robert O'Callahan <>wrote:
>> I think there needs to be a guarantee that the callback is eventually
>> called even if the element never becomes visible. People sometimes want to
>> take action when an animation finishes. window.mozRequestAnimationFrame
>> fires once per second even for hidden tabs for this reason.
> I see your point but I'm a little worried about adding that exception. Take
> the example again. There are 10 areas, 1 is on the screen,
> it's playing video. If once a second all 9 areas have their animationFrame
> callback called that video will probably glitch or stutter once a second.  I
> suppose the UA can stagger the offscreen animationFrame calls but I just
> wonder if calling them at all when they are offscreen is really warranted.
> Or how about I've got in one tab (10 areas), techcrunch.comin another (4 areas),
> in a 3rd (7 areas), in a 4th (3 areas), add a
> few more and soon my machine will end up being bogged down making
> animationFrame callbacks to offscreen tabs.  Is the solution to just keep
> calling each one less and less frequently? I'd prefer it if my under powered
> netbook wasn't spending it's time and battery rendering things offscreen
> ever if possible. Not only that, but as I add more and more tabs I'd like to
> be able to swap them out of memory, but if every second or 2 seconds or 10
> seconds each one gets an animationFrame callback then it will be swapped
> back into memory.

I'm only suggesting that we guarantee the callback is eventually called. You
can throttle it to lower than 1Hz if you want.

If you really want to save power you need to freeze apps completely anyway.
Many apps are already using setTimeout all the time, and they won't all

"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:48:21 UTC