Normal windows are created using XCreateWindow() or XCreateSimpleWindow(), which allocate a set of window attributes and, for InputOutput windows, a front buffer, into which an image can be drawn. The contents of this buffer will be displayed when the window is visible. This extension enables applications to use double-buffering with a window. This involves creating a second buffer, called a back buffer, and associating one or more back buffer names (XIDs) with the window, for use when referring to (i.e., drawing to or reading from) the window's back buffer. The back buffer name is a drawable of type XdbeBackBuffer. DBE provides a relative double-buffering model. One XID, the window, always refers to the front buffer. One or more other XIDs, the back buffer names, always refer to the back buffer. After a buffer swap, the window continues to refer to the (new) front buffer, and the back buffer name continues to refer to the (new) back buffer. Thus, applications and toolkits that want to just render to the back buffer always use the back buffer name for all drawing requests to the window. Portions of an application that want to render to the front buffer always use the window XID for all drawing requests to the window. Multiple clients and toolkits can all use double-buffering on the same window. DBE does not provide a request for querying whether a window has double-buffering support, and if so, what the back buffer name is. Given the asynchronous nature of the X Window System, this would cause race conditions. Instead, DBE allows multiple back buffer names to exist for the same window; they all refer to the same physical back buffer. The first time a back buffer name is allocated for a window, the window becomes double-buffered and the back buffer name is associated with the window. Subsequently, the window already is a double-buffered window, and nothing about the window changes when a new back buffer name is allocated, except that the new back buffer name is associated with the window. The window remains double-buffered until either the window is destroyed, or until all of the back buffer names for the window are deallocated. In general, both the front and back buffers ae treated the same. In particular, here are some important characteristics:

The basic philosophy of DBE is that both buffers are treated the same by X window management operations. When a double-buffered window is destroyed, both buffers associated with the window are destroyed, and all back buffer names associated with the window are freed. If the size of a double-buffered window changes, both buffers assume the new size. If the window's size increases, the effect on the buffers depends on whether the implementation honors bit gravity for buffers. If bit gravity is implemented, then the contents of both buffers are moved in accordance with the window's bit gravity, and the remaining areas are tiled with the window background. If bit gravity is not implemented, then the entire unobscured region of both buffers is tiled with the window background. In either case, Expose events are generated for the region that is tiled with the window background. If the XGetGeometry() function is executed on an XdbeBackBuffer, the returned x, y, and border-width will be zero. If the Shape extension ShapeRectangles, ShapeMask, ShapeCombine, or ShapeOffset request is executed on a double-buffered window, both buffers are reshaped to match the new window shape. The region difference D = new shape - old shape is tiled with the window background in both buffers, and Expose events are generated for D.

DBE has no explicit knowledge of ancillary buffers (e.g. depth buffers or alpha buffers), and only has a limited set of defined swap actions. Some applications may need a richer set of swap actions than DBE provides. Some DBE implementations have knowledge of ancillary buffers, and/or can provide a rich set of swap actions. Instead of continually extending DBE to increase its set of swap actions, DBE provides a flexible "idiom" mechanism. If an application's needs are served by the defined swap actions, it should use them; otherwise, it should use the following method of expressing a complex swap action as an idiom. Following this policy will ensure the best possible performance across a wide variety of implementations. As suggested by the term "idiom," a complex swap action should be expressed as a group/series of requests. Taken together, this group of requests may be combined into an atomic operation by the implementation, in order to maximize performance. The set of idioms actually recognized for optimization is implementation dependent. To help with idiom expression and interpretation, an idiom must be surrounded by two function calls: XdbeBeginIdiom() and XdbeEndIdiom(). Unless this begin-end pair surrounds the idiom, it may not be recognized by a given implementation, and performance will suffer. For example, if an application wants to swap buffers for two windows, and use X to clear only certain planes of the back buffers, the application would make the following calls as a group, and in the following order: