[Webkit-unassigned] [Bug 51218] Implement mozilla's requestAnimationFrame API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=51218





--- Comment #3 from James Robinson <jamesr at chromium.org>  2010-12-17 12:49:38 PST ---
(In reply to comment #2)
> (In reply to comment #1)
> > Here's an initial proposal for webkitRequestAnimationFrame based off of the initial Mozilla proposal, this public-webapps thread: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0644.html, and chatting with roc:
> > 
> > New function on Element:
> > void webkitRequestAnimationFrame(callback);
> > 
> > This indicates that the element is being animated and requests that the browser invoke the callback at some point in the future to update the element's animation state.  At some point after this function is called (for example just before the next repaint), the specified callback is invoked with no arguments and the page can update whatever animation state it needs to (update DOM positions, make WebGL or canvas 2d calls, etc).  The callback is only invoked in cases where the element is (or might soon be) visible - the callback won't be invoked if the tab is hidden or the element is scrolled well offscreen.
> 
> Simple callbacks like this have issues:
> 1. how to you unregister the callback?

We could return an id from the register callback and provide a cancel() interface (like setTimeout/clearTimeout), if cancelling the callback is something we want to support.  I'm not sure of what the immediate need is for this.

> 2. what happens if you call webkitRequestAnimationFrame() twice on the same element? Does it replace the callback, or queue both?

Each call enqueues an additional callback.

> 
> Why is this better than firing an event?

The callback is a one-time thing so that the default behavior is better, so it doesn't really match the event semantics.  Also I find callbacks a little simpler to deal with (but that's more a matter of taste).

> 
> It's not clear to me that bounds-checking the elements is really useful or do-able. How do you know that an element won't be visible for the next frame because of CSS animations, or scrolling?

The important thing about this API is it is always safe to invoke the callback on an element that isn't really visible, so we can be conservative and fire the callback if in doubt.  In the case of CSS animations, WebCore knows what animations are in progress at any point in time so it can either estimate the animation state or just give up and fire the callback on any element that has an in-progress animations.  Fast scrolling is normally implemented by rendering content past the viewport in the scrollable direction by some margin, so we can fire the callback at any elements within this over-rendered region.

I think we'll want to have this flexibility down the road even if we don't take immediate advantage of it (and fire the callback on every element, for example).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.