Re: requestAnimationFrame

On Thu, Nov 18, 2010 at 4:03 PM, Gregg Tavares (wrk) <gman@google.com>wrote:

> On (a)
> Take this page (http://boingboing.net) At the time I checked it today
> (6:55pm PST) it had 10 instances of flash running. O page load 3 were
> animating continuallty, 7 were idle. The 7 idle ones were all video with
> custom UIs. Of those 7, 6 of them will animate constantly once the video is
> finished advertising other videos to play. That means at any one time, if
> this was canvas based, 9 areas will be re-rendered by JavaScript on each
> "animationFrame".  It seems like giving the browser more info by tying these
> animation frames to specific elements would let the browser not call
> animationFrame callbacks unless the element it is tied to is on the screen
> and that would be a pretty good thing. If all 10 of those areas were
> re-rendering their ads all the time I suspect that page would get pretty
> slow, especially on netbooks. As it is, only 1-3 areas are ever visible at
> once.
>

Yeah, that makes sense.

Then I suggest adding requestAnimationFrame to elements, so you can call
"element.requestAnimationFrame(callback)".

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.

It's a little tricky to define exactly what it means for an element to be
visible. I think we could probably leave that up to the UA without hurting
interop.

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]