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

[bugzilla-daemon at webkit.org]

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





--- Comment #4 from Simon Fraser (smfr) <simon.fraser at apple.com>  2010-12-17 13:11:35 PST ---
> > 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.

> > 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"?

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.

> > 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).

Makes sense. Hopefully you can compute visibility when affected by scrolling & software animations before calling the callbacks.

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