Windows: SwapBuffers with Frame Buffer Objects ? +(no-tearing/vsync/swap_interva(1) and scrolling/viewport) ?

[skybu...@hotmail.com]

Frame Buffer Object allow offscreen rendering.

Thus immediately reminds me of tearing problems and vertical sync.

So now the all important question is it actually possible to do this basic operation ?

Swap "offscreen frame buffer object" to "default frame buffer" ?

From reading around the internet it seems that there is something called:

"draw_framebuffer" and "read_framebuffer".

There is also something called:

"front" "back" if default frame buffer (0)

There is also something called

"attachmentpoint0" or something like that.

So let's suppose two frame buffer objects are created.

FrameBufferObject 0 (to get access to default frame buffer)
FrameBufferObject 1 (to create an offscreen frame buffer)

Let's setup a viewport to for both for all I care or one to be applied to both.

FrameBufferObject0 can be set to front
FrameBufferObject1 can be set to attachment point 0

Is it now possible to call "SwapBuffers" from Windows API to actually swap ?!

Or is this basic functionality not available in OpenGL ?

SwapBuffers is very important it seems the only way to work together with swap_interval(1) which sets vertical synchronization to 1.

Also the only other way all of this would make any sense is if offscreen framebuffers, textures, and what not where rendering to "back" buffer first.

To then swap to front ?!?

However "rendering" to back buffer is not so simple, this would require glBlitFrameBuffer or some kind of blit call ?!? Some say this costs 5 milliseconds or so.

I would like to find the best possible way to flip/swap an offscreen frame buffer to the front buffer. Otherwise I see little use for this "frame buffer object".

However I also plan on using CUDA... and I also want the fastest way to "blit/draw" some pixels in cuda to some buffer which is then displayed on screen with no tearing and vertical synchronization.

I have one application setup which uses pixel buffer object and cuda.

Another application which uses front/back double buffering, swapbuffers and vertical sync.

Now I need to merge the two code bases so cuda visualizations can be done with no-tearing ?!

I would like to avoid rendering to texture and then rendering the texture, this seems stupid and possibly unnecessary performance hit ?!?

Later it might be usefull to use a larger then screen offscreen rendering buffer, to use it to scroll across this offscreen framebuffer if altering the viewport settings allows this ?

Is it possible to use offscreen framebuffer + viewport settings to implement a scrolling effect ?

Bye,
Skybuck.

[skybu...@hotmail.com]

This is so annoying, even vulkan swap chain doesn't mention how to setup vertical synchronization:

https://vulkan-tutorial.com/Drawing_a_triangle/Presentation/Swap_chain

Bye,
Skybuck.

[skybu...@hotmail.com]

Checking for "retrace" was just a few assembler instructions in ms-dos/vga graphics cards, why is this so hard now in opengl and vulkan and modern graphics cards ?!?!?

Bye,
Skybuck.

[skybu...@hotmail.com]

FBO examples on the web seem to use glutSwapBuffers instead of SwapBuffers, not sure why, also their examples are so simple it's hard to tell if glutSwapBuffers implement VSYNC or not. Examples run so fast it's likely little to no screen tearing will be visible without additional CPU processing to through off the timing...

Bye,
Skybuck.

[skybu...@hotmail.com]

One of the examples I saw did turn of swap_interval to 0 but still used glutSwapBuffers.

I am not sure why it would turn it off, maybe to prevent double waiting or some bug ?

Anyway documentation for glut seems to indicates it indeed flips the buffer when retrace happens:

Slightly annoyed now that yet another library is needed to implement. I think glut is not present by default on systems, it's not default present on windows and might not be installed by graphics driver, so this would be a glut dll that I might need to supply with my app to make it run, the example didn't come with glut so assumed it was already installed, this might be wrong, I can remember apps not working cause glut was not present, maybe windows 95 or so but still, currently on windows 7.

This was kinda the nice thing about opengl, just one dll, always there on all windows versions, but not so with glut. Maybe if I can find glut source code, might be able to duplicate it's functionality, doubt it though, probably something special ;)


"
4.6 glutSwapBuffers

glutSwapBuffers swaps the buffers of the current window if double buffered.

Usage

void glutSwapBuffers(void);

Description

Performs a buffer swap on the layer in use for the current window. Specifically, glutSwapBuffers promotes the contents of the back buffer of the layer in use of the current window to become the contents of the front buffer. The contents of the back buffer then become undefined. The update typically takes place during the vertical retrace of the monitor, rather than immediately after glutSwapBuffers is called.

An implicit glFlush is done by glutSwapBuffers before it returns. Subsequent OpenGL commands can be issued immediately after calling glutSwapBuffers, but are not executed until the buffer exchange is completed.

If the layer in use is not double buffered, glutSwapBuffers has no effect.
"

Bye,
Skybuck.

[skybu...@hotmail.com]

This guy seems to have discovered that rebinding to default frame buffer, might make swap interval work again, at least this may prevent the usage of glut which is at least something.

I dislike very much how opengl does not document how certain things affect other certain things.

Better to duplicate all kinds of settings in object orientated design, then to leave all these assumptions hanging in the air.

"
muhkuh
Member
Aug 2010

Hi,

I have some code that does this:

render to a FBO
blit the result to the back buffer
swap buffers

This basically works but controlling VSYNC from code by wlgSwapInterval/glxSwapIntervalSGI doesn’t work anymore as it did before when rendering was done directly to the back buffer.

Forcing vsync on/off in the driver control panel still works though. The hardware is nvidia in all cases.

Is there something about FBOs and blitting between them that could cause this? It seems like a driver bug to me but I want to be sure I’m not making a silly mistake myself. Any ideas?

Thanks

Edit:
It seems like the driver doesn’t like it when I leave the FBO active all the time. When I switch back to the default FBO before swapping buffers SwapInterval seems to be effective again. Is this expected behaviour?
"

Bye,
Skybuck.

[skybu...@hotmail.com]

This blit example seems to work, there are some caveats maybe, some depth buffer might also have to be attached and such for 3D work, not sure for 2D work ;)


Here is alternative example which does not require textures:

// copy framebuffer
if(fboUsed)
{
glBindFramebuffer(GL_READ_FRAMEBUFFER, fboId);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glBlitFramebuffer(0, 0, TEXTURE_WIDTH, TEXTURE_HEIGHT,
0, 0, screenWidth, screenHeight,
GL_COLOR_BUFFER_BIT,
GL_LINEAR);
glBindFramebuffer(GL_READ_FRAMEBUFFER, 0);
}

Replace variables in blit with your own.

Apperently frame buffer 0 is front buffer.
fboId is your frame buffer number.

Why such a simple thing is not explained anywhere in opengl documentation is beyond me.

Bye,
Skybuck.

[skybu...@hotmail.com]

This guy describes glutSwapBuffers, might have lag issues.

Maybe swap interval does not have lag issues, so far on my GT 1030 did not notice any lag issues in Quake 3 Arena or so which also has this swap interval implementation, not sure if it uses glut too though.

So far without fbo speed can be 800 to 1200 fps for just clearing screen.

Will now attempt to try and mix my OpenGLControl gui code/component with framebuffers objects to see if it can be done somehow ;)

Otherwise might have to change code, don't have too, but it would be cool to have.

I just hate textures =D

Bye,
Skybuck.