libXext xserver libXau libXinerama update 7/10/2010

1 files changed, 313 insertions, 317 deletions

diff --git a/libXext/man/DBE.man b/libXext/man/DBE.man
index e8263cef3..6199d4917 100644
--- a/libXext/man/DBE.man
+++ b/libXext/man/DBE.man
@@ -1,317 +1,313 @@
-.\" $Xorg: DBE.man,v 1.3 2000/08/17 19:41:55 cpqbld Exp $
-.\"
-.\" Copyright (c) 1995  Hewlett-Packard Company
-.\" 
-.\" Permission is hereby granted, free of charge, to any person obtaining a
-.\" copy of this software and associated documentation files (the "Software"), 
-.\" to deal in the Software without restriction, including without limitation 
-.\" the rights to use, copy, modify, merge, publish, distribute, sublicense, 
-.\" and/or sell copies of the Software, and to permit persons to whom the 
-.\" Software furnished to do so, subject to the following conditions:
-.\" 
-.\" The above copyright notice and this permission notice shall be included in
-.\" all copies or substantial portions of the Software.
-.\" 
-.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-.\" IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-.\" FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL 
-.\" HEWLETT-PACKARD COMPANY BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 
-.\" WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF 
-.\" OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
-.\" SOFTWARE.
-.\" 
-.\" Except as contained in this notice, the name of the Hewlett-Packard Company shall not 
-.\" be used in advertising or otherwise to promote the sale, use or other 
-.\" dealing in this Software without prior written authorization from the 
-.\" Hewlett-Packard Company.
-.\"
-.\" $XFree86: xc/doc/man/Xext/dbe/DBE.man,v 3.4 2001/01/27 18:20:19 dawes Exp $
-.\"
-.TH DBE __libmansuffix__ __xorgversion__ "X FUNCTIONS"
-.SH NAME
-DBE - Double Buffer Extension
-.SH SYNOPSIS
-The Double Buffer Extension (DBE) provides a standard way to utilize
-double-buffering within the framework of the X Window System.
-Double-buffering uses two buffers, called front and back, which hold images.
-The front buffer is visible to the user; the back buffer is not.  Successive
-frames of an animation are rendered into the back buffer while the previously
-rendered frame is displayed in the front buffer.  When a new frame is ready,
-the back and front buffers swap roles, making the new frame visible.  Ideally, 
-this exchange appears to happen instantaneously to the user, with no visual
-artifacts.  Thus, only completely rendered images are presented to the user, 
-and remain visible during the entire time it takes to render a new frame.  The
-result is a flicker-free animation.
-.SH DESCRIPTION
-.B Concepts
-.RS
-Normal windows are created using
-.B XCreateWindow()
-or
-.B 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
-.I (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
-.I 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:
-
-.RS
-Only one buffer per window can be visible at a time (the front buffer).
-
-Both buffers associated with a window have the same visual type, depth,
-width, height, and shape as the window.
-
-Both buffers associated with a window are "visible" (or "obscured") in
-the same way.  When an Expose event is generated for a window, this 
-event is considered to apply to both buffers equally.  When a 
-double-buffered window is exposed, both buffers are tiled with the 
-window background.
-Even though the back buffer is not visible, terms such as obscure apply to the 
-back buffer as well as to the front buffer.
-
-It is acceptable at any time to pass an
-.I XdbeBackBuffer
-in any function that expects a drawable.
-This enables an application to draw directly into
-.I XdbeBackBuffer
-in the same fashion as it would draw into any other drawable.
-
-It is an error (Window) to pass an
-.I XdbeBackBuffer
-in a function that expects a Window.
-
-An
-.I XdbeBackBuffer
-will never be sent in a reply, event, or error where a Window is specified.
-
-If backing-store and save-under applies to a double-buffered
-window, it applies to both buffers equally.
-
-If the
-.B XClearArea()
-or
-.B XClearWindow()
-function is executed on a
-double-buffered window, the same area in both the front and back buffers
-is cleared.
-.RE
-
-The effect of passing a window to a function that accepts a drawable
-is unchanged by this extension.  The window and front buffer are synonymous
-with each other.  This includes obeying the
-.B XGetImage()
-and
-.B XGetSubImage()
-semantics and the subwindow-mode semantics if a graphics context is
-involved.  Regardless of whether the window was explicitly passed in an
-.B XGetImage()
-or
-.B XGetSubImage()
-call, or implicitly referenced (i.e., one of
-the window's ancestors was passed in the function), the front (i.e. visible)
-buffer is always referenced.
-Thus, DBE-naive screen dump clients will always get the front buffer.
-.B XGetImage()
-and
-.B XGetSubImage()
-on a back
-buffer return undefined image contents for any obscured regions of the back
-buffer that fall within the image.
-
-Drawing to a back buffer always uses the clip region that would be used to 
-draw to the front buffer with a GC subwindow-mode of ClipByChildren.  If an 
-ancestor of a double-buffered window is drawn to with a GC having a
-subwindow-mode of IncludeInferiors, the effect on the double-buffered
-window's back buffer depends on the depth of the double-buffered window
-and the ancestor.  If the depths are the same, the contents of the back buffer
-of the double-buffered window are not changed.  If the depths are different,
-the contents of the back buffer of the double-buffered window are undefined 
-for the pixels that the IncludeInferiors drawing touched.
-
-DBE adds no new events.  DBE does not extend the semantics of any existing
-events with the exception of adding a new drawable type called
-.I XdbeBackBuffer.
-
-If events, replies, or errors that contain a drawable
-(e.g., GraphicsExpose) are generated in response to a request, the
-drawable returned will be the one specified in the request.
-
-DBE advertises which visuals support double buffering.
-
-DBE does not include any timing or synchronization facilities.  Applications
-that need such facilities (e.g., to maintain a constant frame rate) should
-investigate the Synchronization Extension, an X Consortium standard.
-.RE
-
-.B Window Management Operations
-
-.RS
-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
-.B XGetGeometry()
-function is executed on an
-.I XdbeBackBuffer,
-the returned x, y, and border-width will be zero.
-
-If the Shape extension
-.B ShapeRectangles, ShapeMask, ShapeCombine,
-or
-.B 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.
-.RE
-
-.B Complex Swap Actions
-
-.RS
-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 
-applications'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:  
-.B XdbeBeginIdiom()
-and
-.B 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:
-
-.RS
-.B XdbeBeginIdiom().
-
-.B XdbeSwapBuffers()
-with XIDs for two windows, each of which uses a swap action of Untouched.
-
-.B XFillRectangle()
-to the back buffer of one window.
-
-.B XFillRectangle()
-to the back buffer of the other window.
-
-.B XdbeEndIdiom().
-.RE
-
-The
-.B XdbeBeginIdiom()
-and
-.B XdbeEndIdiom()
-functions do not perform any
-actions themselves.  They are treated as markers by implementations that can 
-combine certain groups/series of requests as idioms, and are ignored by other
-implementations or for non-recognized groups/series of requests.  If these
-function calls are made out of order, or are mismatched, no errors are sent,
-and the functions are executed as usual, though performance may suffer.
-
-.B XdbeSwapBuffers()
-need not be included in an idiom.  For
-example, if a swap action of Copied is desired, but only some of the planes
-should be copied,
-.B XCopyArea()
-may be used instead of 
-.B XdbeSwapBuffers().
-If
-.B XdbeSwapBuffers()
-is included in an idiom, it should immediately follow the
-.B XdbeBeginIdiom()
-call.  Also, when the 
-.B XdbeSwapBuffers()
-is included in an idiom, that request's swap action will 
-still be valid, and if the swap action might overlap with another request, then 
-the final result of the idiom must be as if the separate requests were executed
-serially.  For example, if the specified swap action is Untouched, and if a 
-.B XFillRectangle()
-using a client clip rectangle is done to the window's back
-buffer after the
-.B XdbeSwapBuffers()
-call, then the contents of the new 
-back buffer (after the idiom) will be the same as if the idiom was not
-recognized by the implementation.
-
-It is highly recommended that API providers define, and application 
-developers use, "convenience" functions that allow client applications to call
-one procedure that encapsulates common idioms.  These functions will
-generate the
-.B XdbeBeginIdiom(),
-idiom, and 
-.B XdbeEndIdiom()
-calls.  Usage of these functions will ensure best possible
-performance across a wide variety of implementations.
-.SH SEE ALSO
-.I XdbeAllocateBackBufferName(),
-.I XdbeBeginIdiom(),
-.I XdbeDeallocateBackBufferName(),
-.I XdbeEndIdiom(),
-.I XdbeFreeVisualInfo(),
-.I XdbeGetBackBufferAttributes(),
-.I XdbeGetVisualInfo(),
-.I XdbeQueryExtension(),
-.I XdbeSwapBuffers().
-
+.\" Copyright (c) 1995  Hewlett-Packard Company

+.\" 

+.\" Permission is hereby granted, free of charge, to any person obtaining a

+.\" copy of this software and associated documentation files (the "Software"), 

+.\" to deal in the Software without restriction, including without limitation 

+.\" the rights to use, copy, modify, merge, publish, distribute, sublicense, 

+.\" and/or sell copies of the Software, and to permit persons to whom the 

+.\" Software furnished to do so, subject to the following conditions:

+.\" 

+.\" The above copyright notice and this permission notice shall be included in

+.\" all copies or substantial portions of the Software.

+.\" 

+.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

+.\" IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,

+.\" FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL 

+.\" HEWLETT-PACKARD COMPANY BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 

+.\" WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF 

+.\" OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 

+.\" SOFTWARE.

+.\" 

+.\" Except as contained in this notice, the name of the Hewlett-Packard Company shall not 

+.\" be used in advertising or otherwise to promote the sale, use or other 

+.\" dealing in this Software without prior written authorization from the 

+.\" Hewlett-Packard Company.

+.\"

+.TH DBE __libmansuffix__ __xorgversion__ "X FUNCTIONS"

+.SH NAME

+DBE - Double Buffer Extension

+.SH SYNOPSIS

+The Double Buffer Extension (DBE) provides a standard way to utilize

+double-buffering within the framework of the X Window System.

+Double-buffering uses two buffers, called front and back, which hold images.

+The front buffer is visible to the user; the back buffer is not.  Successive

+frames of an animation are rendered into the back buffer while the previously

+rendered frame is displayed in the front buffer.  When a new frame is ready,

+the back and front buffers swap roles, making the new frame visible.  Ideally, 

+this exchange appears to happen instantaneously to the user, with no visual

+artifacts.  Thus, only completely rendered images are presented to the user, 

+and remain visible during the entire time it takes to render a new frame.  The

+result is a flicker-free animation.

+.SH DESCRIPTION

+.B Concepts

+.RS

+Normal windows are created using

+.B XCreateWindow()

+or

+.B 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

+.I (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

+.I 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:

+

+.RS

+Only one buffer per window can be visible at a time (the front buffer).

+

+Both buffers associated with a window have the same visual type, depth,

+width, height, and shape as the window.

+

+Both buffers associated with a window are "visible" (or "obscured") in

+the same way.  When an Expose event is generated for a window, this 

+event is considered to apply to both buffers equally.  When a 

+double-buffered window is exposed, both buffers are tiled with the 

+window background.

+Even though the back buffer is not visible, terms such as obscure apply to the 

+back buffer as well as to the front buffer.

+

+It is acceptable at any time to pass an

+.I XdbeBackBuffer

+in any function that expects a drawable.

+This enables an application to draw directly into

+.I XdbeBackBuffer

+in the same fashion as it would draw into any other drawable.

+

+It is an error (Window) to pass an

+.I XdbeBackBuffer

+in a function that expects a Window.

+

+An

+.I XdbeBackBuffer

+will never be sent in a reply, event, or error where a Window is specified.

+

+If backing-store and save-under applies to a double-buffered

+window, it applies to both buffers equally.

+

+If the

+.B XClearArea()

+or

+.B XClearWindow()

+function is executed on a

+double-buffered window, the same area in both the front and back buffers

+is cleared.

+.RE

+

+The effect of passing a window to a function that accepts a drawable

+is unchanged by this extension.  The window and front buffer are synonymous

+with each other.  This includes obeying the

+.B XGetImage()

+and

+.B XGetSubImage()

+semantics and the subwindow-mode semantics if a graphics context is

+involved.  Regardless of whether the window was explicitly passed in an

+.B XGetImage()

+or

+.B XGetSubImage()

+call, or implicitly referenced (i.e., one of

+the window's ancestors was passed in the function), the front (i.e. visible)

+buffer is always referenced.

+Thus, DBE-naive screen dump clients will always get the front buffer.

+.B XGetImage()

+and

+.B XGetSubImage()

+on a back

+buffer return undefined image contents for any obscured regions of the back

+buffer that fall within the image.

+

+Drawing to a back buffer always uses the clip region that would be used to 

+draw to the front buffer with a GC subwindow-mode of ClipByChildren.  If an 

+ancestor of a double-buffered window is drawn to with a GC having a

+subwindow-mode of IncludeInferiors, the effect on the double-buffered

+window's back buffer depends on the depth of the double-buffered window

+and the ancestor.  If the depths are the same, the contents of the back buffer

+of the double-buffered window are not changed.  If the depths are different,

+the contents of the back buffer of the double-buffered window are undefined 

+for the pixels that the IncludeInferiors drawing touched.

+

+DBE adds no new events.  DBE does not extend the semantics of any existing

+events with the exception of adding a new drawable type called

+.I XdbeBackBuffer.

+

+If events, replies, or errors that contain a drawable

+(e.g., GraphicsExpose) are generated in response to a request, the

+drawable returned will be the one specified in the request.

+

+DBE advertises which visuals support double buffering.

+

+DBE does not include any timing or synchronization facilities.  Applications

+that need such facilities (e.g., to maintain a constant frame rate) should

+investigate the Synchronization Extension, an X Consortium standard.

+.RE

+

+.B Window Management Operations

+

+.RS

+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

+.B XGetGeometry()

+function is executed on an

+.I XdbeBackBuffer,

+the returned x, y, and border-width will be zero.

+

+If the Shape extension

+.B ShapeRectangles, ShapeMask, ShapeCombine,

+or

+.B 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.

+.RE

+

+.B Complex Swap Actions

+

+.RS

+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 

+applications'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:  

+.B XdbeBeginIdiom()

+and

+.B 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:

+

+.RS

+.B XdbeBeginIdiom().

+

+.B XdbeSwapBuffers()

+with XIDs for two windows, each of which uses a swap action of Untouched.

+

+.B XFillRectangle()

+to the back buffer of one window.

+

+.B XFillRectangle()

+to the back buffer of the other window.

+

+.B XdbeEndIdiom().

+.RE

+

+The

+.B XdbeBeginIdiom()

+and

+.B XdbeEndIdiom()

+functions do not perform any

+actions themselves.  They are treated as markers by implementations that can 

+combine certain groups/series of requests as idioms, and are ignored by other

+implementations or for non-recognized groups/series of requests.  If these

+function calls are made out of order, or are mismatched, no errors are sent,

+and the functions are executed as usual, though performance may suffer.

+

+.B XdbeSwapBuffers()

+need not be included in an idiom.  For

+example, if a swap action of Copied is desired, but only some of the planes

+should be copied,

+.B XCopyArea()

+may be used instead of 

+.B XdbeSwapBuffers().

+If

+.B XdbeSwapBuffers()

+is included in an idiom, it should immediately follow the

+.B XdbeBeginIdiom()

+call.  Also, when the 

+.B XdbeSwapBuffers()

+is included in an idiom, that request's swap action will 

+still be valid, and if the swap action might overlap with another request, then 

+the final result of the idiom must be as if the separate requests were executed

+serially.  For example, if the specified swap action is Untouched, and if a 

+.B XFillRectangle()

+using a client clip rectangle is done to the window's back

+buffer after the

+.B XdbeSwapBuffers()

+call, then the contents of the new 

+back buffer (after the idiom) will be the same as if the idiom was not

+recognized by the implementation.

+

+It is highly recommended that API providers define, and application 

+developers use, "convenience" functions that allow client applications to call

+one procedure that encapsulates common idioms.  These functions will

+generate the

+.B XdbeBeginIdiom(),

+idiom, and 

+.B XdbeEndIdiom()

+calls.  Usage of these functions will ensure best possible

+performance across a wide variety of implementations.

+.SH SEE ALSO

+.I XdbeAllocateBackBufferName(),

+.I XdbeBeginIdiom(),

+.I XdbeDeallocateBackBufferName(),

+.I XdbeEndIdiom(),

+.I XdbeFreeVisualInfo(),

+.I XdbeGetBackBufferAttributes(),

+.I XdbeGetVisualInfo(),

+.I XdbeQueryExtension(),

+.I XdbeSwapBuffers().

+