Displaying sequence of frames in loop on projector

Dear all,

I have written OpenGL code in combination with the SOIL toolbox to load a series of bitmaps onto the GPU and to display them in a loop, one after the other. The speed at which this happens can be controlled more or less using Sleep() in the idle function, but for now it is being displayed at maximum refresh rate by setting the Sleep to 0.001ms.

The next step for my application would be to output this series of bitmaps (in full screen) on a projector with a refresh rate of 60Hz, making sure that with every refresh (i.e. every newly projected screen) of the projector, a new bitmap is imaged. And this in a let's say infinite loop.

What would be the best way to do this? Can I use OpenGL to incorporate some sort of control so that there are no frame-drops/doubles in the projection? Or am I barking up the wrong tree here?

You should never ever ever use Sleep calls to control framerate. Sleep only guarantees a minimum time to sleep for, and it may actually sleep for any arbitrary amount of time longer. The time specified to sleep for doesn't include the time taken to draw a frame, so it's totally unreliable. The common naive implementation looks something like this:

Code :

while (1)
{
DrawFrame ();
// run at 60fps
Sleep (16);
}

That's not going to run at 60fps.

First of all, your Sleep (16) call may actually sleep for 16ms. Or for 17ms. Or for 10,000ms. You don't have control over this.

Secondly, how long does the frame take to draw? Does it take less that 0.666ms? Does it take 1ms? 2ms? Will a transient condition on the PC cause occasional frames to take 4ms? You can't predict this in advance.

Thirdly, Sleep is commonly based on a system timer that has absolutely lousy resolution. The default resolution of Sleep is in the order of ~15ms. So a Sleep (16) call may actually Sleep for no less than 30ms! There are of course API calls to control this (e.g timeBeginPeriod on Windows) but unless you explicitly use them you're stuck with that lousy resolution.

So your frame time isn't 16ms here. It's 16ms plus whatever arbitrary extra amount of time the OS decides you're going to sleep for, rounded up to the next interval of your sleep timer resolution, plus whatever unpredictable amount of time it takes to draw the frame. It should be obvious - Sleep calls are totally useless for controlling framerate.

Where Sleep is OK is if you want to use it for reducing power usage (there are other ways of doing this however), but it's not OK for controlling framerate, and it's important to understand upfront that these are not two different classes of the same thing.

In order to display at a fixed refresh rate of 60Hz you should use vsync. This can be controlled through OpenGL (e.g via the WGL_EXT_swap_control extension on Windows) and will guarantee that you'll never run faster than the refresh rate of your display device.

You can still run slower though, but again that's something you have little control over. E.g. it may take some time to load a bitmap from disk, it may take some time to transfer it to the GPU, it may take some time to draw it on your backbuffer, and any one of those may be affected by transient conditions on your PC (maybe the OS decides to swap out some inactive memory at the same time as you're reading a bitmap from disk, thereby affecting overall disk IO performance, for example) and may bump you to below 60fps. So you're not going to be able to guarantee that you'll never miss a frame, but you can adapt to things a bit better.

A rough way of doing this might look something like:

Figure how much time has elapsed (in seconds) since the video started (using a high resolution timer).

Multiply this by 60 to get the frame number to show.

If this hasn't changed since the last frame, then don't bother with the rest (you may be able to get away with a Sleep (1) here if you want to reduce CPU usage and if you use the appropriate API to control the resolution of the timer Sleep calls are based on).

Otherwise, convert this frame number to the name of a bitmap file (I'm assuming that you've got some convention that will enable you to do this quickly and easily).

Load and display the bitmap.

Swap buffers.

The only place where a Sleep call may be appropriate here is where I've indicated above; there should not be any other Sleep call anywhere in your main loop. Using this approach, instead of one Sleep (16) call you'll just a bunch of consecutive Sleep (1) calls, followed by a frame, followed by another bunch of consecutive Sleep (1) calls, and that will behave much better.

I am not fixed on using the Sleep() function in any way, it was just the only thing I could come up with yet to control the frame rate. I will have a look at Vsync now, and see if I can use it to make my application work.

One additional question, though: could I not load the bitmaps in advance to the GPU. I need to loop over a sequence of let's say 32 frames that will not change. When frame #32 is displayed, I need to display frame #1 again, and so on... I thought by loading them to texture[1], texture[2], ..., texture[32] before any displaying that this could save me time and thereby benefit the "one frame every 1/60th of a second"-goal. Or is this not how it works?