When swapping between back and front buffers the content in the back buffer becomes undefined. I´d like to define it using the "windowing system", such as GLX, EGL, WGL. Using "native" renderer such as OpenGL (glClear) is my backup plan, don´t bother mentioning it. The reason it is backup is because I don´t want to mess with native rendering contexts. I´ll stick to X/GLX for this question but if you feel inclined to describe how to do it in other Environments then go ahead.
From the Xlib documentation (http://www.x.org/docs/X11/xlib.pdf) I find an operation, XClearWindow, for clearing window with "background pixel" (awesome name by the way... not).
- Does XClearWindow clear front/back or both buffers? I guess back buffer makes sense but I can´t figure it out from Xlib documents alone... And if anyone asked about triple buffers, it wasn´t me!
- Is it synchronous to OpenGL rendering, or do I have to synchronize myself by for example calling glxWaitGL before the operation?
- Is the command blocking, ie halts until complete? Implementation dependent?
Other suggestions as how to clear the back buffer after a swap using windowing system (GLX) is appriciated.
Cheers!
When swapping between back and front buffers the content in the back buffer becomes undefined.
Yes, and that is a good thing.
I´d like to define it using the "windowing system", such as GLX, EGL, WGL
Why? Apart from that doing this is just as undefined, as the background after a swap nothing good will come from it.
At best it will just degrade performance if the OpenGL DDX is aware of the XClearWindow it will sync. At worst you're introducing a race condition between which the results are unpredicatable.
Other suggestions as how to clear the back buffer after a swap using windowing system (GLX) is appriciated.
Use the proper OpenGL operation: glClear(…).
After some research I may have found a solution. The documents seem to be in order but I have not had the chance of testing this in practice. I´ll update the answer with code once I got something working.
Does XClearWindow clear front/back or both buffers?
X does not have the concept of double buffers. Whenever interacting with X against a double buffered window, both buffers are affected. The exception being reading operations such as XGetImage that only operate on the front buffer.
X is however extended with a double buffer concept through the X Double Buffer Extension, or xdbe: http://www.x.org/releases/X11R7.6/doc/xextproto/dbe.html#dbeswapbuffers
xdbe provide the XdbeSwapBuffers operation similar to glxSwapBuffers provided by GLX. There are some important differences:
- XdbeSwapBuffers does not manage any synchronization with any client
API like glxSwapBuffers do. The user has to do this manually. Luckily, GLX provide great
synchronization operations (
glxWaitGL and glxWaitX) that won´t stall
execution. That pretty much answers my second question.
- glxSwapBuffers performs an implicit flush (
glFlush) for the current
context. XdbeSwapBuffers does not. When to flush or not is an
application designer decision.
- XdbeSwapBuffers may swap many windows in one call.
- XdbeSwapBuffers may have different behavior when swapping:
'Undefined', 'Background', 'Untouched', 'Copied'. Read the link
for details.
For clearing after a swap to a predefined color the 'Background' swap behavior is the way to go. What to clear to can be configured through X and may be a pixmap or single color (background pixel).
Is the command blocking, ie halts until complete? Implementation
dependent?
An application using X have to provide its own synchronization mechanisms in many situations. This would indicate an asynchronous execution pattern, but the standard itself does not require it. I´d go with "implementation defined" with a strong suggestion that most commands for most platforms are asynchronously executed.
