[Public WebGL] RequestAnimationFrame stops updating after hitting a breakpoint

Cedric Vivier [email protected]
Wed Feb 9 12:47:29 PST 2011

On Thu, Feb 10, 2011 at 02:11, Gregg Tavares (wrk) <[email protected]> wrote:
>It's only IE that hasn't said if they have plans to
> implement it.
> As for why setTimeout needs to be at the top. It's because setTimeout fires
> X milliseconds after you call it. Let's say you are trying to run at 60fps
> or about 17ms.

I just started hacking on an improved JavaScript 'shim' implementation
of the requestAnimationFrameAPI which removes this limitation, reduces
general latency by using lazily only one setInterval for all
animations within the page, and better matches the semantics of the
I'll later add visibility checks against the viewport per animated
element so that it gets as efficient as possible in JavaScript.

demo @ http://neonux.github.com/requestAnimationFrame.js/demo.html
code @ https://github.com/neonux/requestAnimationFrame.js/

On an interesting note, using the API with multiple animations using
the same rendering callback screams for the API to bind `this' to the
rendering element when calling the callback, which simplifies such use
cases, matches other DOM APIs (eg. addEventListener) and is anyways
definitely more useful than having `this' as window for sure. The shim
normalizes to this behavior for now.
Which WG is more suitable for propose this change to the spec?

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list