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

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from James Robinson <jamesr at chromium.org>  2010-12-17 13:22:35 PST ---
(In reply to comment #4)
> > > 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.
> 
> I think it's always a good idea to allow cancellation for any API that allows registration.

Hard to argue with that :)

> 
> > > 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.
> 
> Even if the callback is the "same"?

Why not?  If I call setTimeout() twice with the same callback I get two timers.

> 
> Some similar issues came up in the discussion of styleMedia.matchMedia() (see bug 37205). Comparing callbacks is hard, which is why I'm hoping to avoid a callback-based solution here.
> 
> > > 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).
> 
> I agree that repeating/not-repeating is the main difference, but I still think event semantics are a better fit. I does worry me that badly behaved content might leave a lot of 'beforePaint' event handlers registered though.
> 

I think that people are used to using setTimeout() to update their animations today, so a one-shot callback based system is much closer to the model that developers are already using.  I think we'll probably want to hash this out in a broader list (public-fx or public-webapps) to get more feedback from other implementors, developers, etc.  There are valid points on both sides.

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