OpenGL ARB Meeting March 9-10 1998 David Yu Minutes of GLX 1.3 Discussion - Reviewed changes to the GLX 1.3 specification made between January 1998 and March 1998 (handout "GLX CHANGES"). - Reviewed comments addressed by changes to the GLX 1.3 specification between January 1998 and March 1998 (handout "GLX DONE"). - Discussed remaining issues. In the time available on Monday, we were unable to go through all of the issues. We hoped to continue the discussion on Tuesday, but ran out of time. GLX 1.3 Issues resolved at the meeting: [page numbers refer to the spec version 1.3 dated 7 March 1998] 1) pp13-14 Change the description of RGBA rendering to single-channel visuals: - specify that red component maps to the color buffer bits corresponding to the core X11 visual - green/blue/alpha map to non-displayed color buffer bits if their sizes are non-zero, otherwise they are discarded. 2) p14 Clarify the specification of minimal required configurations to indicate that: - alpha size may be zero - aux buffers may be zero 3) Observed that there is no way to create a Pbuffer directly from an X11 Visual. Decided that this is okay: Pbuffers can only be created directly from an FBConfig. 4) p4 Noted that Figure 1 has been renamed "Direct and Indirect Rendering Block Diagram" - client state and server state labels will be added to the diagram as suggested by Andy Vesper. 5) Decided to add a new function GLXFBConfig * glXGetFBConfigs(Display *dpy, int screen, int *count); which returns all of the FBConfigs supported on the specified screen. - remove NULL attrib_list semantics from glXChooseFBConfig, which previously was used for this purpose (see next item) - this helps make it clear that and application can use any selection strategy for choosing an FBConfig, it not tied in any way to the selection and sorting criteria specified for glXChooseFBConfig 6) pp16-19 Clarify the description of glXChooseFBConfig - remove NULL attrib_list semantics. Passing either a NULL pointer or an empty list (e.g. { None }) as the parameter to glXChooseFBConfig will both have the same effect, that is to select and sort FBConfigs according to the default criteria. - reorganize the description around three steps: a) argument checking b) FBConfig selection c) FBConfig sorting - explain how a DONT_CARE attribute value is treated with respect to attributes which have an "exact match" selection criteria 7) p20 Clarify the description of glXGetFBConfigFromVisual: - instead of saying "most closely matching visual", specify that if more than one FBConfig is associated with the specified visual, then the FBConfig is returned which sorts first according to the rules specified for glXChooseFBConfig. All rules are considered. 8) p22 Typo replace the words "resource ID" with "XID" 9) p24 For glXCreatePbuffer, remove the requirement that the value None is returned when the command fails to allocate the pbuffer. - this is more consistent with commands like glXCreateGLXPixmap and XCreateWindow - allows the command to be asynchronous w.r.t. the X11 command/reply streams - typically the allocation error will then be reported to the client during the next synchronous request (e.g. glXMakeContextCurrent) 10) p27 Clarify the description of glXMakeContextCurrent with respect to error semantics when the context state is inconsistent with the drawable state. Specifically, explain why color buffers and ancillary buffers are treated differently. [resolution of this issue followed a lengthy discussion] - color buffers are treated specially because the current drawBuffer and readBuffer context state can be inconsistent with the current draw or read drawable (e.g. drawBuffer == GL_BACK and drawable is single buffered) - there is no equivalent way for the context state to be inconsistent with drawable state for other ancillary buffers. - try not to modify the core GL error semantics - if drawBuffer is inconsistent, then rendering is as if drawBuffer == NONE - if readBuffer is inconsistent, then pixel values read are undefined - queries of the drawBuffer and readBuffer state return the current values even if those values are inconsistent with the draw and read drawables. - attempts to set drawBuffer or readBuffer to and unsupported color buffer continues to be an error (consistent with core GL spec) - attempts to read from an unsupported ancillary buffer continues to be an error (consistent with core GL spec) - attempts to set drawBuffer or readBuffer indirectly (i.e. glPopAttrib, glXCopyContext) is an INVALID_OPERATION error. (consistent with core GL spec) 11) p30 Clarify the various uses of bitmasks in the discussion of Events. - change the formal argument name to in the prototypes for the functions glXSelectEvent and glXGetSelectedEvent - change the field name to in the GLXBufferClobberEvent structure 12) p30 Add more context to the discussion of Events. - discuss general relationship to core X11 events and event delivery - GLX Events are returned in X11 event stream - GLX event mask is private to GLX (i.e. is separate from core X11 event mask) - one GLX event mask per client per drawable - discuss the functions glXSelectEvent and glXGetSelectedEvent in the same place 13) p30 Change the name of GLXBufferCloberEvent to GLXPbufferClobberEvent - these event are delivered to clients which have selected pbuffer clobber events - this is done by setting GLX_PBUFFER_CLOBBER_BIT in the parameter to glXSelectEvent and queried by using glXGetSelectedEvent - these events are generated as a result of conflicts in the framebuffer allocation between two drawables when one or both of the drawables are pbuffers - if an implementation doesn't support the allocation of pbuffers, then it doesn't need to support the generation of GLXPbufferClobberEvents - event mask interface and event delivery mechanism is general enough to support further extension if other clobber event types are required. 14) p30 Specify the encoding of the field in the GLXPbufferClobberEvent structure - eight values are currently defined: GLX_FRONT_LEFT_BUFFER_BIT GLX_FRONT_RIGHT_BUFFER_BIT GLX_BACK_LEFT_BUFFER_BIT GLX_BACK_RIGHT_BUFFER_BIT GLX_DEPTH_BUFFER_BIT GLX_STENCIL_BUFFER_BIT GLX_ACCUM_BUFFER_BIT GLX_AUX_BUFFER_BIT - any of these bits can be set in to indicate that the clobber event pertains to the specified buffer(s). - FRONT_LEFT and BACK_LEFT bits are used to specify the front and back color buffers (respectively) of a non-stereo drawable. - aux buffers are treated specially as follows: a) when the GLX_AUX_BUFFER_BIT is set in then the integer field in the event structure is set to indicate which aux buffer was affected. b) if more than one aux buffer was affected then additional events are generated as part of the same contiguous event group. Each additional event will have only the GLX_AUX_BUFFER_BIT set in and the field will be set appropriately. -------- GLX 1.3 Issues not discussed during the meeting 15) What is the relationship between GLXPbufferClobberEvents and X11 Expose events? vesper@vesper.eng.pko.dec.com (Andy V): > Are buffer clobber events generated in addition to X11 expose events for > windows, or instead of them? I hope in addition to. Does it depend on > what events are selected? I hope not. Are buffer clobber events and X11 > expose events required to be in any particular order? I expect not, but > I'm sure they can't be intermingled. dyu@sgi.com (David Yu): GLX buffer clobber events and X11 expose events are selected independently. If a client selects for both, then both will be delivered to the client. Like X11 expose events, all of the buffer clobber events generated as the result of some operation for a given drawable will be returned contiguously to the client. The relative order of X11 event groups and GLX event groups is not specified. 16) What is the state of ancillary buffers following an X11 Expose Event? vesper@vesper.eng.pko.dec.com (Andy V): > If buffer clobber events are not selected, does the X11 expose event > imply anything about the ancillary buffers? I think that an application > must assume that all color and ancillary buffers in the exposed region > are undefined. -and- brokensh@austin.ibm.com (Dan Brokenshire) > What does the GLX_SAVED event_type mean? Does this get returned if a > window is clobbered and backing store is enabled? If so, ancillary > buffers don't typically get saved (to the best of my knowledge) by > the backing store mechanism. dyu@sgi.com (David Yu): Yes, an X11 expose event implies that the corresponding regions of any ancillary buffers of the specified drawable are undefined (See p2 third paragraph). The event masks have no effect on whether buffers are saved or damaged, they only affect whether the corresponding saved or damaged events are generated and delivered to the client. Portions of a Window clobbered by a Pbuffer are always saved. Portions of a Pbuffer clobbered by a Window or another Pbuffer may be saved or discarded (depending on the state of GLX_CONTENTS_PRESERVED when the Pbuffer was created). We may want to add an argument to glXCreateWindow so that it is easy to add an option for GLXWindows to be clobbered, without being saved, by a Pbuffer. Backing store is a separate mechanism and only affects portions of the color buffer managed by core X11. 17) Visual IDs, screens, and depths vesper@vesper.eng.pko.dec.com (Andy V): > Page 34, second paragraph says "The X protocol allows a single VisualID > to be instantiated at multiple depths." I'm not sure of that, but I do > know that you can have the same VisualID on two different screens. dyu@sgi.com (David Yu): Yes. The same reasoning holds. GLX uses VisualInfo records because they uniquely identify a (VisualID,screen,depth) tuple. FBConfigs encapsulate the same information. [actually, the GLX _protocol_ is not robust in the face of VisualID's being instantiated at multiple depths, since the depth information from the VisualInfo is not sent from the client to the server when a context is created (see xGLXCreateContextReq)] 18) RGBA rendering only to TrueColor and DirectColor visuals vesper@vesper.eng.pko.dec.com (Andy V): > Page 35, second paragraph says "RGBA rendering can be supported only by > Visuals of type TrueColor or DirectColor ...." I don't believe this is > correct, but it is true that the glXChooseVisual will not return a > PsuedoColor or StaticColor visual when RGBA rendering is requested. dyu@sgi.com (David Yu): This statement is true in the sense of maintaining backwards compatibility with the VisualInfo based functions. We may want to re state this so that it makes sense in the context of a 1.3 implementation which also supports FBConfigs: "RGBA rendering can be supported only by Visuals of type TrueColor or DirecColor (unless FBConfigs are used), ..." 19) Optimal Pbuffer width/height brokensh@austin.ibm.com (Dan Brokenshire) > Page 16 - First full paragraph > > I find the whole concept of an optimal pbuffer width and height > ambiguous and likely to lead to significantly varying implementations. > The specification considers architectures with fixed tile sizes as the > motivation for specifying the optimal width & height. Is an > implementation expected to report values corresponding to the tile > size? Or some multiple of the tile size? If the prior is true, the > specification needs to indicate so. If the latter is true, how is an > implementation expected to know what multiple the application would be > interested in using? ljp@sgi.com (Jon Leech): Agreed. Perhaps this would be better dealt with by allowing GLX to suggest the "optimal" size closest to the requested buffer size (preferably greater)? 20) Are Pbuffers sharable brokensh@austin.ibm.com (Dan Brokenshire): > 1) Is it required that pBuffers be a sharable resource between > multiple clients? If so, it should be specified. dyu@sgi.com (David Yu): Yes, a Pbuffer (like other drawable types) can be used by any client which can name it (i.e. any client which knows the XID associated with the Pbuffer) 21) Can Pbuffers be enumerated nance@engr.sgi.com (Nancy Cam Winget): > How do we know how many pbuffers are alloced? Is it per display? dyu@sgi.com (David Yu): Like X11 pixmaps and GLXPixmaps, there is no way to enumerate the pbuffers which are currently allocated. 22) Errors/Restrictions for glXCreateWindow and glXDestroyWindow dyu@sgi.com (David Yu): - discuss when ancillary buffers are allocated - specify that it is an error to use glXCreateWindow if there is already and FBConfig associated with - specify what happens if MakeCurrent is used before glXCreateWindow - specify what happens if the core X11 window is destroyed while a client is still rendering to the corresponding GLXWindow -------- END