Re: requestAnimationFrame

On Wed, Nov 24, 2010 at 12:08 PM, Gregg Tavares (wrk) <gman@google.com>wrote:

> requestAnimationFrame though is generally designed to be used for updating
> a canvas (2d or 3d) which will likely be heavy both in terms of CPU usage
> (drawing lots of lines/curves/images into the canvas) and in terms of memory
> usage (accessing lots of images).

So, imagine you have a netbook and you've got 10-20 tabs open (less than I
> usually have open, YMMV). Imagine all the flash content (ads, video UIs) on
> those pages is done with canvas. Imagine there has been enough social
> pressure so that sites that used to use setInterval or setTimeout to update
> their canvas and therefore bog down the browser have switched to
> requestAnimationFrame.
>

You're really stretching my imagination here, but OK...

Now, given that the there's a promise to call the callbacks periodically,
> what would be your solution to fix the issue that the browser is running
> really slow since each time a callback comes in, 10s of megs of images have
> to get swapped in so they can be drawn into a canvas and then swapped back
> out when the next canvas gets it's animationFrame callback?
>

Actually I have one solution that I thought of the other day but forgot to
post here: exponential backoff. Fire the first round of
requestAnimationFrame callbacks in a hidden tab after 1 second. Fire the
next round after 2 seconds, the next round after 4 seconds, etc. That
guarantees that a) "animation end" activity is late by at most the duration
of the animation (or one second, whichever is greater) b) if a tab is hidden
for N seconds, we issue at most log2(N) requestAnimationFrame callbacks for
it and c) we keep the simple promise that if requestAnimationFrame is
called, we eventually fire the callback.

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]