Hi, this is a quick question.
What happenes to the front buffer after I swap buffers, assuming I am in double buffering mode? Will the new back buffer contain the same data as what it had when it was the front buffer, or does it now contain something undefined?
Thanks in advance for the reply.
Coco
Originally posted by Coconut_Crab:
[b]Hi, this is a quick question.
What happenes to the front buffer after I swap buffers, assuming I am in double buffering mode? Will the new back buffer contain the same data as what it had when it was the front buffer, or does it now contain something undefined?
Thanks in advance for the reply.
Coco[/b]
Swapping buffers functionality doesn’t belong to OpenGL, it belongs to the glue layer between OpenGL and the OS (WGL, GLX or AGL).
In WGL what happens depends on the pixelformat you have selected:
With the glAddSwapHintRectWIN extension function, two new flags are included for the PIXELFORMATDESCRIPTOR pixel format structure. Value Meaning
PFD_SWAP_COPY Specifies the content of the back buffer in the double-buffered main color plane following a buffer swap. Swapping the color buffers causes the content of the back buffer to be copied to the front buffer. The content of the back buffer is not affected by the swap. PFD_SWAP_COPY is a hint only and might not be provided by a driver.
PFD_SWAP_EXCHANGE Specifies the content of the back buffer in the double-buffered main color plane following a buffer swap. Swapping the color buffers causes the exchange of the back buffer’s content with the front buffer’s content. Following the swap, the back buffer’s content contains the front buffer’s content before the swap. PFD_SWAP_EXCHANGE is a hint only and might not be provided by a driver.
Note that both flags are hints, so check for the PIXELFORMATDESCRIPTOR returned by the driver when you query it with DescribePixelformat . In the default case, the content of the backbuffer is undefined after a swap (which may even change in runtime depending on the window layout - you may get sometimes a swap and sometimes a blit).
If you want to use your backbuffer as a backstorage, the safest way is to use glCopyPixels to copy from the back to the frontbuffer.
Hi! 
The opengl documentation file I have for win32, which is actually part of the Platform SDK, has a small section on just that!
I don’t know where I got this file, but it’s called opengl.chm and about 650 K large.
Under “Win32 extensions to opengl”->“OpenGL on Windows NT, Windows 2000, and Windows 95/98”->“Front, Back, and Other Buffers”->“Buffer Functions” it explains what happens to the buffers clearly.
And sure, like evanGLizr says, after a swap the content is undefined. 
Thank you for the replies. They are both very helpful.
But as you said, that the data might be undefined after the buffer swapping, how can I make sure if I want to save the screen to a BMP file the file will be correct?
I cannot copy the back buffer to a file after the swapping because the data might be undefined on different OSs, and in the FAQ on this website it is said that if I copy the content of the OpenGL window while another window overlaps that window, I will copy what’s on top of the OpenGL window.
So, should the solution be, creating a BMP file, copy the content of the back buffer to the BMP, then swap the buffer?
I just want to render an image to a file, that’s all. I’ve read the red book in which it said I could render the image to a buffer instead of to the screen, but it didn’t have a code example to demostrate that. Can someone enlighten me on how to do it?
Thanks in advance for any helps.
Coco
Oh and I just searched my C drive for opengl.chm, but couldn’t find it. Mind telling where I can find it, maybe somewhere on the internet?
Thanks.
So, should the solution be, creating a BMP file, copy the content of the back buffer to the BMP, then swap the buffer?
yes.
Neither the front nor the back buffer are defined to be valid for areas of the viewport that are overlapped by other windows. Thus, you can’t take a good screen shot (necessarily) if, for example, the user has a Windows Media Player window, or Internet browser, overlapping your window. You must render to a pbuffer to be sure that all parts of your back buffer are valid.
i’m just curious about it. it works for me even with overlapped windows. i had to read back the back buffer because the front buffer had the limitations that were already discussed.
Originally posted by jabe:
i’m just curious about it. it works for me even with overlapped windows. i had to read back the back buffer because the front buffer had the limitations that were already discussed.
It’s implementation dependent. OpenGL specs are pretty clear about it:
“4.1.1 Pixel Ownership Test
The first test is to determine if the pixel at location (xw, yw) in the framebuffer
is currently owned by the GL (more precisely, by this GL context). If it is not,
the window system decides the fate the incoming fragment. Possible results are
that the fragment is discarded or that some subset of the subsequent per-fragment
operations are applied to the fragment. This test allows the window system to
control the GL’s behavior, for instance, when a GL window is obscured.”
That means you can’t draw into overlapped regions reliably and if you can’t draw into some areas it’s futile to read from there either:
“ReadPixels obtains values from the selected buffer from each pixel with lower
left hand corner at (x+i, y+j) for 0 <= i < width and 0 <= j < height; this pixel
is said to be the ith pixel in the jth row. If any of these pixels lies outside of the
window allocated to the current GL context, the values obtained for those pixels
are undefined. Results are also undefined for individual pixels that are not owned
by the current context. Otherwise, ReadPixels obtains values from the selected
buffer, regardless of how those values were placed there.”
That it worked for you doesn’t mean it works on other implementations.
That it worked for you doesn’t mean it works on other implementations.
of course. i cannot check any available implementations. i just answered from my experiences.
nevertheless, some things become clearer now. thanks.
Can someone please give me a code example on how to render an image to a user defined buffer?
Also, if I want to copy the content of the back buffer to a user defined buffer, should the pixel copying code be in the place right before GlutSwapBuffers(), assuming I am using Glut?
Thanks.
Coco
Look at the spec for WGL_ARB_pbuffer.
Basically, you allocate the pbuffer DC, allocate a GLRC on that DC, and wglMakeCurrent() to draw in that buffer. Then treat it as any other GL context. wglShareLists() will work IF the pbuffer is “compatible” with the screen, which is somewhat ill-defined.
If you’re not on Windows, I presume other OS-es have a similar extension.
I hope all OSs have this by now.
GLX_SGIX_pbuffer
http://oss.sgi.com/projects/ogl-sample/registry/SGIX/pbuffer.txt
GL_APPLE_pixel_buffer
http://developer.apple.com/opengl/extensions.html#GL_APPLE_pixel_buffer
Is there an OS independent way of allocating a buffer and tell OpenGL to render to that buffer? Does OpenGL have a native way to do it already or does it have to go through the OS? In the OpenGL Red Book it’s only mentioned that we can render to an offscreen buffer, but it doesn’t say it has to use an OS dependent routine, nor does it have a code example in the book.
No, but pretty soon this should happen, and even then it will take time for it to be available on every system. See the other long thread with 46 posts.
If you want demoes using WGL, see http://download.nvidia.com/developer/SDK/Individual_Samples/samples.html
I think glCopyPixels will flush the
opengl command.
if you glCopyPixels before
swap buffer;the data is correctly.
No, pixel ownership test comes first. Read my post above.
If you want an unclipped offscreen buffer with hardware rendering you must use p-buffers today.
Thanks, yjh1982, I’ll try that.
And what is a p-buffer? I mean what’s the difference between a p-buffer and a regular buffer?
Is there an OS independent way of allocating a buffer and tell OpenGL to render to that buffer?
No. Until this point, surface and context allocation have been reserved for the host windowing system, and OpenGL has been focused on rasterization.
what is a p-buffer?
Exactly that which is specified by the WGL_ARB_pbuffer and GLX_SGIX_pbuffer specifications.