The Problem of Vsync

This is one of the things the Amiga did really well. Among its specialized hardware was the Copper, which was a very simple processor whose clock was tied to the video clock. You could use it to schedule blits (using the Blitter, another special bit of hardware whose specialty was moving rectangular bits of rasters around) and other operations (like moving hardware sprites around) immediately after the CRT beam passed the location where it was being drawn. So with careful planning, you could get all your draws done without tearing and without having to resort to double buffering.<p>I recall hearing that the reason the Video Toaster was an Amiga exclusive piece of hardware was the availability of the video clock as well.<p>I miss that stuff. But not all the time, double and triple buffering are certainly much easier. It was also possible quite easily to do double buffering on the Amiga, and I think it was probably much more common than the bare-metal copper approach. But for people who really wanted that level of control, it was there.

This is an issue that I've been interested lately. I've been prototyping a yet-another-gl-context-lib (like sdl,glut), and this is one of the issues that I wanted to focus on.<p>On apple platforms, there is CVDisplayLink (osx) and CADisplayLink (ios), that triggers a notification on the vsync interrupt, which should give rock solid framerate-stability with minimum cpu-usage.<p>I've yet to find similar solutions to other modern platforms, which is a little disappointing. Though there is hope that vsync swapping is implemented little more sanely on other platforms. Also dwm (windows compositing window manager) has some more knobs to tune, don't know if they help.<p>For the input-lag, handling messages in a different thread than rendering should work, but doesn't help with battery-draining.<p>And also the input that comes as messages (keys, mouse) have timestamps on them, not sure if they are granular enough though. So while it might come with lag, at least you should be able to simulate the game state so it makes sense with the inputs you've provided<p>I wonder, do media players on windows work with pure luck or do they attempt some kludges try to keep the framerate stable, without burning the cpu/battery?

I'm surprised that there's not some kind of real time-ish callback when the screen is about to update, giving the game a last chance to update its buffer?<p>Or better yet there should be a way of saying "use this buffer next time you update the screen" (and don't block during vblank time).

I regret that DirectX won over OpenGL.

Is this a problem on Linux as well? See, those of us developing graphics drivers view vsync as the best thing since sliced bread for its ability to make our composited desktops and movie players tear-free. If GLX can't properly do this for people, I'd be interested in hearing what game developers want, since we hear from them so infrequently.