[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] RequestAnimationFrame stops updating after hitting a breakpoint



On Thu, Feb 10, 2011 at 02:11, Gregg Tavares (wrk) <gman@google.com> 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
API.
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?


Regards,
-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------