This chapter describes resource control extensions, which are extensions to GLX. GLX is an extension to the X Window System that makes OpenGL available in an X Window System environment. All GLX functions and other elements have the prefix glX (just as all OpenGL elements have the prefix gl).
You can find information on GLX in several places, including the following:
Introductory information—See the glxintro man page.
In-depth coverage—See Appendix C, “OpenGL and Window Systems,” of the OpenGL Programming Guide and OpenGL Programming for the X Window System.
See “OpenGL and Associated Tools and Libraries” for bibliographical information.
This chapter explains how to use extensions to GLX. The following extensions are presented in alphabetical order:
The following sections describe extensions that are experimental:
Using OpenGL in an X Window System environment is described in the following chapters of this guide:
The import context extension, EXT_import_context, allows multiple X clients to share an i ndirect rendering context. The extension also adds some query routines to retrieve information associated with the current context.
To work effectively with this extension, you must first understand direct and indirect rendering. See “Direct and Indirect Rendering” in Chapter 4 for some background information.
You can use the extension to import another process' OpenGL context, as follows:
To retrieve the XID for a GLX context, call glXGetContextIDEXT():
GLXContextID glXGetContextIDEXT(const GLXContext ctx)
This function is client-side only. No round trip is forced to the server; unlike most X calls that return a value, glXGetContextIDEXT() does not flush any pending events.
To create a GLX context, given the XID of an existing GLX context, call glXImportContextEXT(). You can use this function in place of glXCreateContext() to share another process' indirect rendering context:
GLXContext glXImportContextEXT( Display *dpy, GLXContextID contextID)
Only the server-side context information can be shared between X clients; client-side state, such as pixel storage modes, cannot be shared. Thus, glXImportContextEXT() must allocate memory to store client-side information.
A call to glXImportContextEXT() does not create a new XID. It merely makes an existing XID available to the importing client. The XID goes away when the creating client drops its connection or the ID is explicitly deleted. The object goes away when the XID goes away and the context is not current to any thread.
To free the client-side part of a GLX context that was created with glXImportContextEXT(), call glXFreeContextEXT():
void glXFreeContextEXT(Display *dpy, GLXContext ctx)
glXFreeContextEXT() does not free the server-side context information or the XID associated with the server-side context.
Use the extension to retrieve the display of the current context or other information about the context, as follows:
To retrieve the current display associated with the current context, call glXGetCurrentDisplayEXT(), which has the following format:
Display * glXGetCurrentDisplayEXT( void );
If there is no current context, NULL is returned. No round trip is forced to the server; unlike most X calls that return a value, glXGetCurrentDisplayEXT() does not flush any pending events.
To obtain the value of a context's attribute, call glXQueryContextInfoEXT():
int glXQueryContextInfoEXT( Display *dpy, GLXContext ctx, int attribute,int *value )The values and types corresponding to each GLX context attribute are listed in Table 6-1.
Table 6-1. Type and Context Information for GLX Context Attributes
GLX Context Attribute
Type
Context Information
XID
XID of the share list context
XID
Visual ID
int
Screen number
The make current read extension, SGI_make_current_read, allows you to attach separate read and write drawables to a GLX context by calling glXMakeCurrentReadSGI(), which has the following prototype:
Bool glXMakeCurrentReadSGI( Display *dpy,GLXDrawable draw,
GLXDrawable read, GLXContext gc )
|
The variable items are defined as follows:
| dpy | Specifies the connection to the X server. | |
| draw | Specifies a GLX drawable that receives the results of OpenGL drawing operations. | |
| read | Specifies a GLX drawable that provides pixels for glReadPixels() and glCopyPixels() operations. | |
| gc | Specifies a GLX rendering context to be attached to draw and read. |
In GLX 1.1, you associate a GLX context with one drawable (window or pixmap) by calling glXMakeCurrentSGI().The function glXMakeCurrentReadSGI() lets you attach a GLX context to two drawables: you draw to the first one and the second serves as a source for pixel data.
In effect, the following calls are equivalent:
glXMakeCurrentSGI(context, win) glXMakeCurrentReadSGI(context, win, win) |
Having both a read and a write drawable is useful—for example, to copy the contents of a window to another window, to stream video to a window, and so on.
The write drawable is used for all OpenGL operations. Accumulation buffer operations fetch data from the write drawable and are not allowed when the read and write drawable are not identical.
The read drawable is used for any color, depth, or stencil values that are retrieved by glReadPixels(), glCopyPixels(), glCopyTexImage(), or glCopyTexSubImage(). It is also use by any OpenGL extension that sources images from the framebuffer in the manner of glReadPixels(), glCopyPixels(), glCopyTexImage(), or glCopyTexSubImage().
The following is some additional information about the two drawables:
The two drawables do not need to have the same ancillary buffers (depth buffer, stencil buffer, and so on).
The read drawable does not have to contain a buffer corresponding to the current GL_READ_BUFFER of a GLX context. For example, the current GL_READ_BUFFER may be GL_BACK, and the read drawable may be single-buffered.
If a subsequent command sets the read buffer to a color buffer that does not exist on the read drawable—even if set implicitly by glPopAttrib()—or if an attempt is made to source pixel values from an unsupported ancillary buffer, a GL_INVALID_OPERATION error is generated.
If the current GL_READ_BUFFER does not exist in the read drawable, pixel values extracted from that drawable are undefined, but no error is generated.
Operations that query the value of GL_READ_BUFFER use the value set last in the context, regardless of whether the read drawable has the corresponding buffer.
When glXMakeCurrentReadSGI() associates two GLX drawables with a single GLX context, a BadMatch X protocol error is generated if either drawable was not created with the same X screen.
The color, depth, stencil, and accumulation buffers of the two drawables do not need to match. Some implementations may impose additional constraints, such as requiring that the color component resolution of both drawables be the same. In such cases, a BadMatch X protocol error will be generated.
The function glXGetCurrentReadDrawableSGI() returns the name of the GLXDrawable currently being used as a pixel query source.
If glXMakeCurrent() specified the current rendering context, then glXGetCurrentReadDrawableSGI() returns the drawable specified as draw by that glXMakeCurrent call.
If glXMakeCurrentReadSGI() specified the current rendering context, then glXGetCurrentReadDrawableSGI() returns the drawable specified as read by that glXMakeCurrentReadSGI() call.
If there is no current read drawable, glXGetCurrentReadDrawableSGI() returns None.
The visual info extension, EXT_visual_info, enhances the standard GLX visual mechanism as follows:
You can request that a particular X visual type be associated with a GLX visual.
You can query the X visual type underlying a GLX visual.
You can query whether a visual supports a transparent pixel value and query the value of the transparent pixel.
Note that the notions of level and transparent pixels are orthogonal as both level 1 and level 0 visuals may or may not support transparent pixels.
To find a visual that best matches specified attributes, call glXChooseVisual():
XVisualInfo* glXChooseVisual( Display *dpy, int screen, int *attrib_list ) |
The following heuristics determine which visual is chosen:
Table 6-2. Heuristics for Visual Selection
If an undefined GLX attribute, or an unacceptable enumerated attribute value is encountered, NULL is returned.
More attributes may be specified in the attribute list. If a visual attribute is not specified, a default value is used. For more details, see the man page for glXChooseVisual().
To free the data returned from glXChooseVisual(), use XFree().
Note that GLX_VISUAL_TYPE_EXT can also be used with glXGetConfig().
How you specify that you want a visual with transparent pixels depends on the existing attributes:
If ... | Then call glXChooseVisual() and specify as the value of GLX_TRANSPARENT_TYPE_EXT ... |
GLX_RGBA is in attrib_list. | GLX_TRANSPARENT_RGB_EXT |
GLX_RGBA is not in attrib_list. | GLX_TRANSPARENT_INDEX_EXT |
Do not specify one of the following values in attrib_list because typically only one transparent color or index value is supported:
GLX_TRANSPARENT_INDEX_VALUE_EXT
GLX_TRANSPARENT_{RED|GREEN|BLUE|ALPHA}_VALUE_EXT
Once you have a transparent visual, you can query the transparent color value by calling glXGetConfig(). To get the transparent index value for visuals that support index rendering, use GLX_TRANSPARENT_INDEX_VALUE_EXT. For visuals that support RGBA rendering, use GLX_TRANSPARENT_{RED|GREEN|BLUE}_VALUE_EXT. The visual attribute GLX_TRANSPARENT_ALPHA_VALUE_EXT is included in the extension for future use.
“Creating Overlays” in Chapter 4 presents an example program that uses a transparent visual for the overlay window.
The visual rating extension, EXT_visual_rating, allows servers to export visuals with improved features or image quality but with lower performance or greater system burden. The extension allows this without having to have these visuals selected preferentially. It is intended to ensure that most—but possibly not all—applications get the “right” visual.
You can use this extension during visual selection. While you will get a good match for most systems, you may not get the best match for all systems.
To determine the rating for a visual, call glXGetConfig() with attribute set to GLX_VISUAL_CAVEAT_EXT. The function glXGetConfig() returns the rating of the visual in the parameter value, which will be either GLX_NONE_EXT or GLX_SLOW_EXT.
If the GLX_VISUAL_CAVEAT_EXT attribute is not specified in the attrib_list parameter of glXChooseVisual(), preference is given to visuals with no caveats (that is, visuals with the attribute set to GLX_NONE_EXT). If the GLX_VISUAL_CAVEAT_EXT attribute is specified, then glXChooseVisual() matches the specified value exactly. For example, if the value is specified as GLX_NONE_EXT, only visuals with no caveats are considered.
 | Note: The functionality of SGIX_fbconfig was promoted to a standard part of GLX 1.3, which is supported on all current Silicon Graphics visualization systems. For new applications, use the GLX 1.3 equivalent functions and tokens instead of this extension. For a description of framebuffer configurations in GLX 1.3, see section “Using Visuals and Framebuffer Configurations” in Chapter 4. Since the GLX 1.3 features are similar to this extension, the lengthy description is not repeated here. |
| Note: The functionality of SGIX_pbuffer was promoted to a standard part of GLX 1.3, which is supported on all current Silicon Graphics visualization systems. For new applications, use the GLX 1.3 equivalent functions and tokens instead of this extension. For a description of pixel buffers in GLX 1.3, see section “Using Pixel Buffers” in Chapter 4. Since the GLX 1.3 features are similar to this extension, the lengthy description is not repeated here. |