Screen Synchronization Help

OpenGL uses the name 'SwapBuffers' instead 'Flip'. You can use GraphicsContext.VSync = true; to enable vertical retrace synchronization. Enabling VSync will synchronize plain and stereo rendering on both primary and secondary devices (monitors, projectors, ...).

Caveats:

• VSync may not work on windowed applications. This is driver- and OS-dependent.
• VSync will not synchronize clustered rendering or multiple GPUs. You will have to use the 'swap groups' extension, which is not exposed by OpenTK yet (this extension was added to drivers only recently).
• OpenTK does not provide anything equivalent to WaitForVerticalRetrace() (a blocking call that waits until a retrace occurs). Typical VSync is both faster and more reliable.

What exactly are you trying to achieve?

I see. Some clarifications first: the RenderFrequency property is a "soft" limiter. It will limit the rate of RenderFrame events, but it will not sync them to the monitor's refresh rate.

What you need to do:

1. Make sure you are using a CRT monitor. TFTs are completely unsuitable for this task.
2. Create a Fullscreen GameWindow (use GameWindowFlags.Fullscreen on its constructor).
3. Set its RenderFrequency to 0 (i.e. unlimited). You can do this either by calling GameWindow.Run() with 0 its second parameter or by setting the property to 0 manually in the GameWindow constructor.
4. Set GameWindow.VSync = VSyncMode.On. This is a "hard" limiter that will bind RenderFrame events to your monitor's refresh rate.
5. Render the same checkerboard pattern for 4 frames and change it every fifth frame (75Hz / 5 = 15Hz update rate for the pattern).

This will accomplish goal A. Check your driver options and ensure the "vsync" or "vertical synchronization" option is *not* set to "force disabled". It should be either "application defined" or "force enabled" (the exact strings may read differently).

Goal B is a little more tricky: graphics drivers may buffer one or more frames to improve performance. I don't know if the intel drivers allow you to control this (nvidia and ati drivers do), but check for and *disable* any option that reads similar "triple buffering".

Using regular double buffering and assuming ideal conditions (constant 75Hz framerate, CRT monitor), this will give you an error margin of 0-15ms between a call to SwapBuffers() and the appearance of the result on screen. Far from ideal.

The next part is pure speculation, so you'll have to experiment:

• If SwapBuffers() is a blocking call, you can generate a sync event with a great deal of certainty: just wait for SwapBuffers() to return.
• However, some drivers try to improve performance by returning from SwapBuffers() immediately. These drivers will typically block on the *next* OpenGL command after SwapBuffers() and only if the swap hasn't already occurred. (This is quite useful for typical applications, because you can place CPU-consuming tasks right after a SwapBuffers() for free).
• A more accurate solution you can split the VGA cable that connects your monitor and detect its the vblank signal. This will give you the best possible accuracy, but it's slightly more difficult to implement.
• Finally, there might be some WGL/GLX/AGL extension that notifies you of swap events. I've never seen such a thing, however.

I have another question:

Instead of re-drawing the entire scene every frame, can I just point to something in memory and say "use this." And instead change the pallette so that black --> white, and then white --> black?

-S!

--------------------------------------------
a. Mobile Intel 945GM
b. Intel Core2 T7200
c. XP pro
d. .NeT 3.5
e. version A05 (as provided by dell)