Re: requestAnimationFrame

On Wed, Nov 17, 2010 at 5:20 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Nov 18, 2010 at 11:22 AM, Gregg Tavares (wrk) <gman@google.com>wrote:
>
>> Think about this some more..... the point if the previous suggestion is
>> that updating keeping a JS animation in sync with a CSS animation has
>> nothing to do with "painting" or rendering. The fact that apparently firefox
>> ties those 2 things together is an artifact of firefox's implementation.
>> It's just has valid to for example have animation running on 1 thread and
>> rendering on another. Many console/pc games do this. To keep animations in
>> sync requires syncing the animation values in the animation thread, not
>> deciding to update values during rendering.
>
>
> But for maximum smoothness you want to update your animation once per
> painted frame. It doesn't matter how many threads you use and whether you do
> it "during" rendering.
>
>
>>  So, if the goal is to let JS sync with CSS animations, putting the in
>> events related to painting is the wrong model. Solving that problem
>> particular goal it would make more sense to add a "cssAnimationTick" event
>> or something.  Any JS that wants to say in sync would add an event handler
>>
>> window.addEventHandler('animationTick", updateAnimations, ...);
>>
>> The handler would get passed a clock similar to how beforePaint works now.
>>
>
> Let's not get hung up on the "beforePaint" name. As Cameron mentioned, we
> should probably just ditch the event from the proposal altogether.
>
> Of course going down that path doesn't solve the issue I'm trying to solve
>> which could be stated as
>>
>> *) Don't render from JS unless visible (ie, don't execute expensive 2d or
>> 3d canvas rendering calls when not visible)
>>
>
>> With the caveats of
>>
>>   a) Make it extremely easy to do the right thing so that few if any sites
>> making canvas ads or canvas games hog the CPU when not visible.
>>   b) don't make the browser wait on JavaScript.
>>   c) don't render more than needed. (ie, don't render 60 frames a second
>> if you're only changing stuff at 15)
>>
>
> Those are good goals, except I think we need to drill down into (c). Are
> people changing stuff at 15Hz for crude performance tuning, or for some
> other reason?
>

Let's ignore (c) for the moment. I feel with (a) and (b) alone there are
still issues to discuss.

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.


>
> 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]
>