First, FPS is a rotten benchmark to profile against. Use ms/frame – it’s linear and allows for relative comparison. Converting your numbers, we have 0.5ms and 2ms per frame.
Second, swap the glFlush at the end of onDisplay() with a glFinish(). Otherwise you’re timing doesn’t have anything to do with “rendering” frames – just “queuing” frames. Driver will see a glFlush() and go merely on queuing for the next frame, and you’ll block at completely random points in the queuing of a frame’s GL commands.
[QUOTE=Dark Photon;1252087]… swap the glFlush at the end of onDisplay() with a glFinish(). Otherwise you’re timing doesn’t have anything to do with “rendering” frames – just “queuing” frames. Driver will see a glFlush() and go merely on queuing for the next frame, and you’ll block at completely random points in the queuing of a frame’s GL commands.[/QUOTE] Isn’t it recommended to use an Idle Function to do animation as opposed to putting a redisplay in the display routine?
[QUOTE=Triffid;1252149Could you please show me, how would you use glutPostRedisplay properly in my code?[/QUOTE]
I posted an example of how to do animation using an Idle Function in the thread ‘problem with 2 rotating cubes’. Not sure if this would speed up your code, but it should at least give you constant screen update rates.
If I see the point of your technique, the redisplay process must be outside of the display function, handled by keyboard events or idle functions. But how should i define the idle function, when I need to run the scene idependently on the input?
[QUOTE=Triffid;1252173]… how should i define the idle function, when I need to run the scene independently on the input?[/QUOTE] Not sure what you are asking. In the example I posted I show how to define the idle function using keyboard input. I also show how to undefine it (with ‘NULL’) parameter. You don’t explicitly call an idle function. All you have to do is define it (or undefine it). Once it is defined, OpenGL automatically calls it after the display routine is called. Basically you are in an infinite loop until the idle function is undefined (Nulled). Your idle function would be the 4 lines of code called in your display routine which deal with the variables ‘direction’ and ‘spherex’. Take those out of the display function and put them into the idle function. Once again see my example for details.
I’d advise that first of all you get rid of that single-buffered context. I’d honestly love to see all GLUT tutorials that create a single-buffered context being consumed by a very large, very hot fire. You’d almost think that using double-buffered was in some way an advanced topic, but it’s not - it’s two lines of code.
Now you’ve got a nice double-buffered context that will work better with the way your GPU is designed to work, so try things out and see what happens from there.
Unfortunately, frame buffering is not the problem. I had been using it at first, but i thought it can be the cause, so i removed it. But the performance problem remains with enabled or disabled double buffering.
Did anyone try to compile my example code to ensure they experience the same problem?