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.
Live Labs / Seadragon
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Robert O'Callahan
On Sun, Apr 18, 2010 at 8:38 AM, Thatcher Ulrich <firstname.lastname@example.org> wrote:
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?