Hi Guys
I am trying to find where all my main loop time is going and
this snippet below returns 17ms, why is it taking 17ms just to tell opengl
to go and draw everything and swap buffers.
I was under the impression that OpenGL ran concurrently so it should n9ot
have any impact on my game,
I once had a Linux system with a Matrox G400 and a broken OpenGL driver that,
in some configurations, actually allowed the application to run “concurrently”
- until the command buffer was full, which could be tens of frames ahead of
the current display.
It was utterly useless for any sort of real time animation! 
is SDL_GL_SwapBuffers(); doing anything more?
What it should be doing is swap the back (“work”) and front (“display”)
buffers. Preferably, the actual swap should be done by an interrupt handler or
hardware mechanism that ensures synchronization with the vertical retrace of
the video output signal, and the API call should somehow synchronize your
application with the resulting display frame rate.
That’s where those 17 ms are coming from; that’s the approximate period you
get with a standard 60 Hz refresh rate. (Those deltas are probably alternating
between 16 and 17 ms, if you look carefully.)
Also, a steady, “load independent” rate like that means you have retrace sync
enabled and working properly. That’s the way it should be, unless you’re
pushing the limits of underpowered hardware (tearing is sometimes better than
dropping to 50% of the refresh rate), or just want to do some benchmarking.
Anyway, whether or not there is retrace sync, you have a concept of "frames"
on the display side of OpenGL, and just buffering up commands for umpteen
frames ahead of time (either because the GPU can’t keep up, or because you’re
rendering faster than the display refresh rate) would be of little use. It
would just add a gradually increasing delay between your application’s state,
and the visible output.
So, implementations tend to either actually block until the vertical retrace,
or until the actual swap has been performed, or more specifically, until your
"new" back buffer is available for rendering. (The latter is a more accurate
description if you’re using triple buffering - which is also a hint as to why
triple buffering can result in higher frame rates.)
Uhm… That’s a lot of info in one go. 
The short version (that tends to leave people wondering why it’s designed this
way), is "You have vertical retrace (or VBlank) sync enabled, and thus, your
application is synchronized with the display refresh rate."On Saturday 05 December 2009, at 21.15.16, Patricia Curtis <patricia.curtis at unboxedgames.com> wrote:
–
//David Olofson - Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’