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

(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?

• This is very interesting question. – Notabene Jan 12 '11 at 12:33

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.

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.

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.

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.

• -1 for lack of sourcing; OpenGL documentation is plentiful and easily linked. – user744 Jan 12 '11 at 13:24
• +1 because, well, he actually answered and the answer was correct. Sources definitely help, but are by no means required! – o0'. Jan 13 '11 at 15:48
• @Lo'oris: Except, well, he's not correct. He's correct for some platforms, but not all, as my answer explains. – user744 Jan 13 '11 at 16:14
• @Joe: The only answer that is correct regardless of the "environment" is this one, as your answer explains. Coding knowing this will break "somewhere" would be wrong in the first place. – o0'. Jan 13 '11 at 16:15
• @Lo'oris: All code, especially rendering code, is likely to break somewhere. A good answer doesn't just say that, but explains where that somewhere is. – user744 Jan 13 '11 at 16:19

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.

• Wow, negative votes. I'm serious about what I wrote about though - especially if you're writing for mobile hardware, be sure to include that clear there. – Jari Komppa Jan 13 '11 at 15:51
• I downvoted because your answer is almost identical to David's, still has no references, and like David's, is not correct nor the whole story. – user744 Jan 13 '11 at 16:15
• Ok. The only reference I can give, however, is my own experience. I shall be more careful. – Jari Komppa Jan 13 '11 at 16:53
• I downvoted because this answer was strictly worst then the other two (which I both upvoted): it added nothing and was much less clear. – o0'. Jan 14 '11 at 12:49