Programming in GL is similar to programming in a low-level language; small investments in programming effort can lead to large performance gains. Furthermore, different machines and adapters execute drawing commands at different relative drawing rates. An understanding of the type of hardware your code runs on can help you get optimal performance.
For example, there are many ways to draw a rectangle:
Which of these methods draws the rectangle most quickly depends on the type of hardware on which the code is executing. The end goal also determines the choice of subroutines. If you want to clear the entire window and its z-buffer, the czclear subroutine is the fastest method of achieving this. But if you want to clear only a portion of the window, the sboxf subroutine executes faster than a combination of the scrmask and clear subroutines.
The previous discussion is only an example. There are several ways to perform nearly any graphics operation. Where speed is critical, so is design. The following paragraphs discuss some of the performance implications of new or modified subroutines.
| lmcolor subroutine | If the design calls for changing material properties often, consider the lmcolor subroutine. By using the lmcolor subroutine, you can avoid using the relatively slowly executing combination of the lmdef and lmbind subroutines. If the lmcolor subroutine cannot be used, then perform all transactions with the lmdef subroutine before drawing. This method pulls the relatively slowly executing lmdef subroutine out of the performance-critical drawing loop. |
| curson, cursoff subroutines | In the current release of GL, the curson
and cursoff subroutines turn the cursor visibility on and off.
However, they execute fairly slowly and should not be heavily used.
GL formerly required the cursor to be turned off before any drawing was done, and turned on again after drawing completion. This is no longer required. However, existing code that is being ported to the current release may often make use of this function. This code should be modified to remove these subroutines, or the subroutines should be effectively removed by using the #ifdef condition with the C programming language preprocessor. Not doing so can result in a severe performance impact will be observed. |
| mapcolors, getmcolors subroutines | If the design employs color maps or color map mode, use the mapcolors
and getmcolors
subroutines. Using these subroutines improves performance 10 to 1,000 times
over using the mapcolor
or getmcolor
subroutines inside a drawing loop.
Color maps are managed by the X server. The server updates the color map as change requests come into it. The mapcolor and mapcolors subroutines make one change request to the X server every time they are called. Because there is considerable system overhead in communication with the X server process, change requests are processed most efficiently if they are buffered and sent as one request by using the mapcolors subroutine. |
| concave subroutine | The concave subroutine causes the system to use more robust, but slower algorithms to render concave polygons correctly. If all affected polygons are convex, the applications programmer should disable the concavity check; this causes the system to use faster algorithms for polygon rendering. On most adapters, the performance improvement gained by disabling concave polygon-checking should be noticeable. |
| getcolor, getcpos, getgpos, getmatrix, gRGBcolor subroutines | |
| These routines must query the graphics adapter to obtain the information that they return. Due to the current graphics adapter design, there is a significant amount of latency in such an operation. For the returned data to be valid, the graphics adapter must complete all preceding operations that may be queued for execution. In some cases, the queue may be quite deep, or some operations may take a long time. Therefore, the amount of time it takes any of these five routines to execute is variable, and could be quite long, depending on the contents of the queue. To obtain maximum performance, the use of these routines should be avoided. | |
| scale subroutine | If lighting is enabled, and the scale subroutine is called with unequal arguments, the system is forced to renormalize all normal vectors. On some adapters, there is a noticeable performance improvement if the scale subroutine is not used with unequal arguments. |
Most graphics applications are event driven. When developing such applications, keep in mind that the responsiveness is highly dependent on the rate of arrival of events. In particular, the mouse transmit rate can have a tremendous impact on look and feel performance (that is, how the system appears to respond to a mouse movement).
The reason for this is easy to understand. Many applications try to perform some fixed (and possibly large) amount of processing per mouse event. For example, the update and redraw of a slider, a scrollbar, or a 3D viewing parameter. High mouse transmit rates cause a large number of events to be queued up, and an application that does not discard some fraction of these events appears to be slow and sluggish. In contrast, low mouse transmit rates cause the same application to appear light and responsive.
Following are several remedies you can use to improve user-interface response.
Note: Currently, there is no interface in GL, nor in AIXwindows, that controls this transmit rate.
This remedy is acceptable for prototype and non-commercial code. However, if the application is meant to be marketed to a broad customer base, it is not wise to depend strongly on the mouse transmit rate. Setting the mouse transmit rate may adversely affect other applications; and conversely, if other applications set the mouse transmit rate, your application may be adversely affected.
You can reduce the number of REDRAW events issued to a GL application by changing the window manager default for feedback boxes. To do this, add the following to the $HOME/.Xdefaults file:
Mwm*showFeedback:restart
This setting causes the window manager not to display the small window size and position indicator that is normally shown when you move or resize a window. When it is on, this small indicator box (located in the center of the screen) can land on a GL window and generate REDRAW events. Multiple REDRAW events can result in significant performance impact on applications which take a long time to regenerate a window.
You can improve polyline drawing performance by using the polylinelist subroutine. The polylinelist subroutine helps eliminate the subroutine interface calling overhead of the bgnline ... v ... v ... endline interface. Subroutine calling overhead into the GL library can exceed one microsecond per call.
On the POWER Gt4 and POWER Gt4x adapters, and on the POWER Gt4, POWER Gt4x, and POWER GXT1000 adapters, the use of the rectread and rectwritesubroutines is deprecated. The lrectread and lrectwrite subroutines provide a faster, more efficient interface to pixel transfers. The format of the pixels can be adjusted with the pixmode subroutine.