This section describes the interoperability between GL applications and Enhanced X-Windows and discussing interoperability issues such as queue handling and synchronization. The interoperability topics discussed in this section are as follows:
The mapping of GL windows can be deferred by creating them using a noport; winopen; subroutine combination. The mapwin.c example program illustrates this usage. However, the following warning applies:
Attention: One should NEVER draw into a recently mapped window until after a REDRAW (MapNotify) event has been received for that window. For a window to be ready for GL rendering, it must not only be mapped, but the X server must complete a number of internal computations. After the X server has properly set up the window, it will generate a REDRAW (MapNotify) event for that window. Any drawing done prior to the receipt of the REDRAW event will result in a race condition: drawing orders may be lost or ignored, or other unrelated unpredictable behaviors may result (such as the inconsistent placement of the mapped window). Invoking XSync is NOT sufficient to guarantee that the X server has completed mapping the window.
By default, there is no guaranteed synchronization between actions performed through the Enhanced X-Windows programming interface (hereafter termed X) and the GL programming interface. In particular, there is no guarantee that drawing done with X and drawing done with GL will appear on the screen in the same order as performed by the application.
The underlying reason for this asynchronous behavior is the differing GL and X drawing models. The X server does all X drawing, and much of the rest of X processing. The processing does not actually occur until the X server is scheduled to run by the operating system; in the meantime, work requests are queued up. In contrast, all GL drawing subroutines send drawing orders to the graphics adapter directly; the adapter, in turn, renders as fast as possible.
Note: For some harware systems, there is no synchronization of drawing across GL windows resulting in asynchronous windows input.
Synchronization of X and GL drawing can be re-established by using the finish subroutine and the XSync subroutine. The finish subroutine will block (will not return) until all GL primitives have been rendered. The XSync subroutine flush the X display connection.
Use of the XSync subroutine does not guarantee that all X drawing is complete; it only guarantees that the Windows Server has received all generated Windows protocol packets. The Windows Server and/or adapter can still be in the process of rendering when the XSync subroutine returns. Since the latency between the Windows Server's receipt of a protocol packet and the completion of rendering to the screen is almost never more than a few milliseconds, this latency should normally not be noticeable.
On the POWER Gt4 and the POWER Gt4x adapters, there is no guarantee that drawing is synchronized between different windows belonging to the same process. That is, a line drawn in one window may appear on the screen before a polygon is drawn in another window, even though the application made the subroutine call to draw the polygon before the subroutine call to draw the line. This de-synchronization occurs because a separate FIFO (first-in, first-out queue) is maintained for every window. All drawing commands are placed as tokens into the FIFOs. The graphics hardware has been designed to service the FIFOs in a round-robin fashion; the hardware does not necessarily drain one FIFO before moving on to the next. As a result, tokens in one FIFO may be processed before tokens in another, even though they were placed in the FIFO at a later time.
In most cases, the synchronization jitter should be on the order of milliseconds, or less, and should therefore be visually unobservable. If it is absolutely vital to re-establish synchronization, the finish subroutine can be used. The finish subroutine blocks (does not return to the calling application) until all buffers/FIFOs associated with the current window have been drained. The finish subroutine guarantees, in effect, that all drawing sent to a window has appeared on the screen.
The /user/include/gl/gl.h file contains three typedefs that collide with X11 Toolkit Header files. These typedefs are as follows:
To avoid this collision, adhere to following directions:
By doing this, the X11 types will hold, and the GL types will be undefined.
These three typedefs were in the /usr/include/gai/g3dm2types.h file and have been moved to the /usr/include/gl/gl.h file.
The typedefs Boolean and String were colliding with similiar typedefs in the /usr/include/X11/Intrinsic.h file while Object collided with a structure definition in the /usr/include/X11/Object.h file. The following was placed in /usr/include/gl/gl.h file to alleviate the type collisions.
This scenario requires that any include of XToolkit header files must occur before any include of /usr/include/gl/gl.h file. While using mixed mode programming the X11 types are the only valid types.