What is the contents of the buffer *after* a call to glSwapBuffers()?

Question

(SDL_GL_SwapBuffers() in particular)

When you have drawn a scene, and you call swap-buffers, it is routine to then glClear() the scene before drawing anything; if you don't clear, what is the contents of the buffer? Is this defined by any specification, or does it vary by driver?

Answer 1

The details of how to swap the front and back buffer vary from platform to platform, and so the answer is platform-dependent.

According to the GLX glXSwapBuffers reference documentation:

The contents of the back buffer become undefined after a swap. Note that this applies to pixel buffers as well as windows.

However, there exists the GLX_EXT_buffer_age extension:

The aim of this extension is to expose enough information to applications about how the driver manages the set of front and back buffers associated with a given surface to allow applications to re-use the contents of old frames and minimize how much must be redrawn for the next frame.

But Win32 SwapBuffers only says:

If the current pixel format for the window referenced by this device context includes a back buffer, the function exchanges the front and back buffers... If the current pixel format for the window referenced by the device context does not include a back buffer, this call has no effect and the content of the back buffer is undefined when the function returns.

And CGLFlushDrawable, for OS X Core Graphics says:

If the backing store attribute is set to false, the buffers can be exchanged rather than copied. This is often the case in full-screen mode. If the receiver is not a double-buffered context, this call does nothing.

Finally, in OpenGL ES standard buffer-swapping function eglSwapBuffers:

The color buffer of surface is left undefined after calling eglSwapBuffers.

So what does all this mean?

• To be truly cross-platform, you can't assume anything about the back buffer after a swap. Its content is undefined, and you should probably glClear or otherwise fix it up before using it.
• If you are using Linux, you can check for the buffer age extension. Because a system might be triple buffered you may have to keep track of multiple frames worth of damage and deal with that.
• If you are using OS X, you might get copied, and you might get an exchange. So you can assume that the contents of the backbuffer is not garbage, but you don't control whether it's the frame you just sent or the one before that.
• If you are only targeting Win32 and are sure you have a back buffer, you can presumably assume its contents are now what was in the front buffer. (Although this is an assumption from omission rather than explicitly stated; I would not be surprised if it doesn't work on many/any configurations.)

Given the constraints of GLX and CGL, and a desire to minimize changes between OpenGL and OpenGL ES, you might as well just assume the contents are garbage.

Answer 2

From what i have read the only behaviour is UNDEFINED. So i would assume there is no guarantee to what will be the contents of the buffer. Not to mention that some libs actually wrap a clear call into the swap buffers call.

Answer 3

The behavior is UNDEFINED, so if you're going to fill the whole screen anyway, you may consider dropping the clear.. except, on some environments (certain tiling architectures at least), that will actually degrade performance. The full screen clear at the start of rendering is so common operation that I'd be surprised if it wasn't optimized well on all target platforms.

Reason why it's UNDEFINED is that for many architectures, making the content state defined would be an extra overhead, regardless of how you'd define the standard.

As to what you'll find there, I can take a guess based on experience;

On double (or multi-) buffered architectures, like most desktop PC video hardware, you'll likely find the "other" buffer data. This is not guaranteed though, as it's not in the spec, if some weird optimization benefits from it, they will garble the data.

On tiled architectures, you might find the same data as the last frame, some oddly garbled data based on the tile size, or just about anything else.

Then you have some oddball architectures (like the NDS) which might give you just about anything, as their definition of the buffer isn't exactly what you'd expect.