Hello everybody,
I have a big timing problem.
I made several tests to see what is the delay between an OpenGL command and its execution. And I’m so surprised about the results. I’ve made a very simple scene, with a single white rectangle (with or without display lists) and when I tell OpenGL to render it by swaping the buffers (double buffering), my rectangle is displayed only 20-30 ms later. I find it huge and can’t explain this.
I though OpenGL and recent video cards could give us really good and quick results, but actually the execution is delayed about 2 or 3 frames. Is this because of the architecture of the PCs ?
I tried with or without vertical retrace, at 85Hz, and there is the same delay.
I’m working on a P4 3.2Ghz, with a Geforce2 video card, Windows XP. The tests of the delay have been done with an external real time machine. The computer sends a signal to the real-time acquisition machine to tell it that it’s going to render and swaps the buffers. Then the displayed rectangle is “seen” by a photo-diode placed on the screen which converts the image in an electrical signal towards the real-time machine. So the real-time machine can compute the difference between the first signal and the electrical signal of the photo-diode. And here we are, 20-30 ms !
This is so sad because I need to go under these 30ms delay. I tried with another simple program provided by Nehe (lesson 2) and this is even worst (50 ms).
Can anyone who knows everything about OpenGL explain me what this is about ? I donc’t know if this is the place to talk about technical and timing OpenGL things …
I understand why I can loose one frame, if I’m syncronized with the screen, but I can’t explain why loosing 2 or 3 frames every time.
By the way, all the images are computed and displayed, I made several tests in order to be sure of this. So I’m not loosing any image, but all the images (85 per second) will be delayed. So if I decide to display the rectangle every two frames, every image is correctly displayed (one black, one with the rectangle, one black, one rectangle …). But with a delay of 30ms. It’s like I have a permanent delay from the beginning which is never reduced.
try glFlush() or maybe glFinish(). glFlush is implicitely called by swapbuffers, but who knows.
You can experiment with drawing direclty to GL_FRONT buffer and calling glFlush/finsish.
But the caching you describe is designed to be efficient for more complex scenes. ie, this delay won’t increase much with complexity. All the graphic cards were called “pipes” back in SGI times, makes sense that a delay exists between in and out, even if flow is huge.
And 1/50th of a second delay is actually very quick for almost all 3D for humans.
EDIT : http://www.visionegg.org/Intro_and_Overv…Synchronization
found this, talking about 2 frame delay. The explanation looks flawed though (double-double buffering seems fishy). Triple buffering can sometimes be controlled in driver control panel.
Thanks ZbuffeR.
I already used glFlush and even glFinish. The glFinish blocks my code for a few ms so it seems to wait until the GPU finishes all its computations. But the delay is still there.
Thank you very much for your link. At last someone doesn’t tell me that such a delay is impossible in OpenGL and that my computer has a bug 
Funny their protocole is the same as mine that’s exactly what I did (I even used the same photodiode they used ). I’m almost happy to see that someone else was concerned about the same problem …
So I can stop all my tests and continue coding my application, telling myself that it will never be better than this so I can continue developpment.
Thanks again I feel better I was almost crying seeing all my results every time without any explanations … though the explanation is unclear for now (triple buffering from OpenGL ?) but at least they noticed the same delay. I’m not crazy.
Definite explanation is in the hands of card manufacturers, not openGL users 
But it certainly stems from pipelined processing , there is an animation helping to grasp the concept.
For short : better throughput, higher latency.