Course the openGLR graphics with the XWindow system

Sommaire: Course the openGLR graphics with the XWindow system


1 Overview
2 GLXOperation
2.1 Rendering Contexts and Drawing Surfaces
2.2 Using Rendering Contexts
2.3 Direct Rendering and Address Spaces
2.4 OpenGL Display Lists
2.5 Texture Objects
2.6 Aligning Multiple Drawables
2.7 Multiple Threads
3 FunctionsandErrors
3.1 Errors
3.2 Events
3.3 Functions
3.3.1 Initialization
3.3.2 GLX Versioning
3.3.3 Conguration Management
3.3.4 On Screen Rendering
3.3.5 O  Screen Rendering
3.3.6 Querying Attributes
3.3.7 Rendering Contexts
3.3.8 Events
3.3.9 Synchronization Primitives
3.3.10 Double Buering
3.3.11 Access to X Fonts
3.4 Backwards Compatibility
3.4.1 Using Visuals for Conguration Management
3.4.2 O Screen Rendering
3.5 Rendering Contexts
4 EncodingontheXByteStream
4.1 Requests that hold a single extension request
4.2 Request that holds multiple OpenGL commands
4.3 Wire representations and byte swapping
4.4 Sequentiality
5 ExtendingOpenGL
6 GLXVersions
6.1 New Commands in GLX Version 1.1
6.2 New Commands in GLX Version 1.2
6.3 New Commands in GLX Version 1.3
7 Glossary

Extrait du course the openGLR graphics with the XWindow system

Chapter1 Overview
This document des cribes GLX, the Open GLextension to the XWindow System. It refers to concepts discussed in the Open GL specication, and maybeviewedasanXspecicappendixto that document. Partsofthe document assume some acquaintance with both OpenGL and X.
In the XWindowSystem,OpenGLrenderingis madeavailableasan extensionto Xin the formal Xsense: connectionandauthentication are accomplished with the normal X mechanisms.As with other X extensions, there is adenednetworkprotocolfor the OpenGLrendering commands encapsulated within the X byte stream.
Chapter2 GLXOperation
2.1 RenderingContextsandDrawingSurfaces
The OpenGL specication is intentionally vague on howarendering context (an abstractOpenGLstate machine)is created. Oneofthe purposesof GLXis toprovideameansto createanOpenGLcontext andassociateit  with a drawing surface.
In X,arendering surface is calledaDrawable. Xprovidestwotypes ofDrawables: Windowswhicharelocated onscreenandPixmapswhichare maintained oscreen. TheGLXequivalent to aWindowis aGLXWindow andthe GLXequivalent to a Pixmapis aGLXPixmap. GLXintroduces athird typeofdrawable, called aGLXPbuffer, for whichthere is noX equivalent. GLXPbuffers areusedfor oscreenrendering butthey have dierent semantics thanGLXPixmaps that make it easier to allocate them in non-visible frame buer memory.
GLXWindows,GLXPixmaps andGLXPbuffers arecreatedwithrespectto aGLXFBConfig; the GLXFBConfigdescribesthe depthofthe color buer components and the types, quantities and sizes of theancillary buers(i.e.,the depth,accumulation,auxiliary, andstencilbuers). Doublebuering and stereo capability is also xed by theGLXFBConfig.
2.2 UsingRenderingContexts
OpenGL denes both client state and server state.Thus a rendering context consists of two parts:one to hold the client state and one to hold the server state.Each thread can have at most one current rendering context. In addition,a rendering context can be current for only one thread at a time. The client is responsible for creating a rendering context and a drawable.Issuing OpenGLcommandsmaycausethe Xbuerto be ushed. In particular,callingglFlushwhenindirect rendering isoccurring,will ush both the X and OpenGL rendering streams.
2.3 DirectRenderingandAddressSpaces
One of the basic assumptions of the X protocol is that if a client can name anobject,thenit can manipulate thatobject. GLXintroduces the notion ofanAddressSpace. AGLXobjectcannotbe used outsideoftheaddress space in which it exists.
In a classic UNIX environment, each process is in its own address space. In amulti-threadedenvironment, eachofthe threads willshare avirtual address space which references a common data region.
2.4 OpenGLDisplayLists
MostOpenGLstate is small andeasilyretrievedusingthe glGet*com-mands.Thisis nottrue ofOpenGLdisplaylists, whichareused,for ex-ample,to encapsulateamodelofsome physicalobject. First,there is no mechanism toobtainthecontentsofadisplay list from therendering con-text. Second, display lists may be large and numerous.It may be desirable for multiple rendering contexts to share display lists rather than replicating that information in each context. GLX provides for limited sharing of display lists.Since the lists are part of the server context state they can be shared only if the server state for the sharingcontextsexistsin asingleaddressspace. Usingthismechanism,a single set of lists can be used, for instance, by a context that supports color index rendering and a context that supports RGBA rendering.
2.5 TextureObjects
OpenGLtexture state canbeencapsulatedin anamedtexture object. A texture object is created by binding an unused name to one of the texture targets(GLTEXTURE1D, GLTEXTURE2DorGLTEXTURE3D) of a rendering con-text. When a texture object is bound, OpenGL operations on the target to which it is bound aect the bound texture object, and queries of the target to which it is bound return state from the bound texture object.
Texture objectsmaybeshared byrendering contexts, aslong asthe serverportionofthecontextssharethesameaddressspace. (Likedisplay lists, textureobjectsarepartoftheservercontextstate.) OpenGL makes noattempttosynchronizeaccesstotextureobjects. If atextureobjectis bound to more than one context, then it is up to the programmer to ensure that the contents of the object are not being changed via one context while anothercontext is usingthe texture objectfor rendering. Theresults of changing a texture object while another contextis using it are undened.

.....