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

RE: [Public WebGL] Resurrecting Update Scheduling

The problem (as I’ve encountered) is that setTimeout/setInterval do not guarantee callbacks occur at the specified time, and tend to drift *a lot* (much better in Chromium and Safari than others). Even if I set my interval to 1ms, I’ll probably only get ever 10ms, and even then it’ll be 10 with a stddev of 5 due to the way that timers are handled in the event queue. If I’m trying to render in sync with the display (which, as pointed out, I may not even know what its native timing is) this will lead to almost always being unaligned with the display interval. For smooth and sexy presentation a single dropped frame is devastating.


Having a mechanism that is considered high priority and always goes before any other pending work in the event queue would allow for guaranteed callback delivery at a consistent timing, regardless of the work load in other parts of the system. Apple has CADisplayLink on the iPhone for this very reason – relying on NSTimer and the runloop caused dropped frames/desynced draws.



Ben Vanik

Live Labs / Seadragon


From: owner-public_webgl@khronos.org [mailto:owner-public_webgl@khronos.org] On Behalf Of Robert O'Callahan
Sent: Saturday, April 17, 2010 2:38 PM
To: Thatcher Ulrich
Cc: Kenneth Russell; public webgl; Chris Marrin; Vladimir Vukicevic
Subject: Re: [Public WebGL] Resurrecting Update Scheduling


On Sun, Apr 18, 2010 at 8:38 AM, Thatcher Ulrich <tu@tulrich.com> wrote:

Without a JS update scheduler that is vsync aware, the app won't be able to update the scene in sync with the display.


Can you explain why in more detail? I don't understand the issue. If the application script is updating its content at 60 FPS (where "updating the content" includes drawing into a WebGL buffer), and the browser composites the content to the screen during the vsync interval, why would it matter whether the script actually runs during the vsync interval?

I agree with Vlad that we need a mechanism for JS animation that gives frame rate control to the browser, and this mechanism should not be specific to WebGL or canvas. My specific proposal for such a mechanism was mentioned in
See the associated thread.

"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]