VSync logic : UPS / FPS

Hi
First of all, no, I'm not asking how to enable/disable vertical sync.
I'm already using setSwapInterval, and it's working very well.

I would juste like to understand interactions between vsync, and buffer swap.

When i swap buffers, either using autoSwap or calling it by myself, what's happening if vertical sync is enabled :
- Is my call blocking ?
- Is my call delayed until vsync occurs ? If so, what happends if I do call swapBuffer twice before a vsync ? Do I overwrite a the - first buffer before it to be blit on screen ?
- Is my buffer cloned somewhere, and blit on vsync event ?

It just makes me crazy to see that I'm not able to adjust Updates per Second and Frames per Second in my game.

So, If anyone could bring me some light, it would be very helpfull !

Thanks in advance,

Camille

I think u got the wrong idea about OpenGL command execution here. The command u issue via OpenGL are NOT directly fed to the GPU. OpenGL implementations are almost always pipelined, wich means things are not necessarily drawn when you tell OpenGL to draw them, and the fact that an OpenGL call returns doesn't mean it finished rendering.

Normally the OpenGL driver implements some kind of FIFO queue. When your application sends commands to OpenGL, the driver places them into the FIFO and returns to your application. Then the driver decides what to do when and in an order wich is best suited for ur underlying graphics hardware.

So what I stated above applies also for the swapBuffer command. Some drivers choose to block the call until the vertical retrace occurs, some don't. It also often depends on the setting u use with the driver implementation. E.g. if u use triple buffering the swapBuffer command does ofcourse NOT block until retrace, but instead until the third buffer is completely rendered.

If u really want to force emptying the command queue u can call glFinish/glFlush. I wouldn't recommend using these commands as it generally hurts performance in multibuffer environments and really fucks up rendering performance on SLI/Crossfire systems. So the best advice is to leave it up to the driver implementation to decide when to render and in wich buffer.

>Is my buffer cloned somewhere, and blit on vsync event ?

Typically all renderbuffers are created upfront when u initialze ur OpenGL context. E.g. when u use triple buffering, 3 buffers are created. When a vertical retrace occurs the buffer wich has completed rendering is 'flipped' wich just means that a pointer to the buffers memory used by the RAMDAC is changed wich is very fast. The 'old' screen buffer from the previous frame then becomes the new buffer for rendering.

>It just makes me crazy to see that I'm not able to adjust Updates per Second and Frames per Second in my game.

Why do u want to update more frequently than u can display ? U wont be able to see what u have rendered anyway so why bother ?

 

Thanks a lot for your quick answer.

Just to resume : swapBuffer command may block at execution time (mean : when it appears to be on the bottom of the FIFO), or may not, depending on the driver implementation.
In any case, my java call shouldn't be blocking.
That makes sense.

Concerning  update/display frenquencies, I agree with you : I've no interest in having an update frequency higher than my vertical refresh.
That's why I 'm trying to understand how all the update/vsync/display mechanism works.
Today, with a simple Animator and with VSync activated, I get 60fps on a 60Hz screen (wahoo !), but the 'display' event is called about 100 times per second on my renderer. It's just a waste  of ressources I would like to avoid.


*Edit : some BIG mistakes. Sorry for my crap english and for the remaining ones.

>Today, with a simple Animator and with VSync activated, I get 60fps
>on a 60Hz screen (wahoo !), but the 'display' event is called about 100
>times per second on my renderer. It's just a waste  of ressources I
>would like to avoid.

With "my renderer" u mean the GLEventListener ur animator calls ? If so ur display method on the GLEventListener method is only called 60 times per second when VSync is on (assuming the default 60hz LCD refresh) and ur Animator is set to "RunAsFastAsPossible". When u get 100 display calls per second theres something wrong with ur code.

Maybe u could provide some code snippets to clear things up ?

Also take a look at the JOGL demos e.g. "Gears" http://github.com/sgothel/jogl-demos/blob/master/src/demos/gears/Gears.java and try the simple demo on ur machine. I'm sure u will immediatly see that the display method is only called in sync with ur display refresh (60hz). If Gears has the correct display method call count and ur code does not u know that theres stg wrong with ur code.