OpenGL Programming Guide

Chapter 4Display Lists

Display-List Design Philosophy

OpenGL display lists are designed to optimize performance, particularly over networks, but never at the expense of performance on a local machine. A display list resides with the OpenGL server state, which in a networked environment might be on a different machine than the host (or client state). "What Is OpenGL?" discusses OpenGL's client-server model.

To optimize performance, an OpenGL display list is a cache of commands rather than a dynamic database. In other words, once a display list is created, it can't be modified. If a display list were modifiable, performance could be reduced by the overhead required to search through the display list and to perform memory management. As portions of a modifiable display list were changed, memory allocation and deallocation might lead to memory fragmentation. Using display lists is typically at least as fast as using immediate mode. Display lists can substantially increase performance - particularly when you issue OpenGL routines across networks, since display lists reside with the server and network traffic is minimized.

Even locally, a display list might be more efficient since it can be processed as it's created into a form that's more compatible with the graphics hardware. The particular commands that are so optimized may vary from implementation to implementation. For example, a command as simple as glRotate*() might show a significant improvement if it's in a display list, since the calculations to produce the rotation matrix aren't trivial (they can involve square roots and trigonometric functions). In the display list, however, only the final rotation matrix needs to be stored, so a display-list rotation command can be executed as fast as the hardware can execute glMultMatrix(). A sophisticated OpenGL implementation might even concatenate adjacent transformation commands into a single matrix multiplication.

Although you're not guaranteed that your OpenGL implementation optimizes display lists for any particular uses, you know that execution of display lists isn't slower than executing the commands contained within them. There is some overhead, however, involved in jumping to a display list. If a particular list is small, this overhead could exceed any execution advantage. The most likely possibilities for optimization are listed below, with references to the chapters where the topics are discussed.

• Matrix operations (Chapter 3 ). Most matrix operations require OpenGL to compute inverses. Both the computed matrix and its inverse might be stored by a particular OpenGL implementation in a display list.
  
  

• Raster bitmaps and images (Chapter 4 ). The format in which you specify raster data isn't likely to be one that's ideal for the hardware. When a display list is compiled, OpenGL might transform the data into the representation preferred by the hardware. This can have a significant effect on the speed of raster character drawing, since character strings usually consist of a series of small bitmaps.
  
  

• Lights, material properties, and lighting models (Chapter 6 ). When you draw a scene with complex lighting conditions, you might change the materials for each item in the scene. Setting the materials can be slow, since it might involve significant calculations. If you put the material definitions in display lists, these calculations don't have to be done each time you switch materials, since only the results of the calculations need to be stored; as a result, rendering lit scenes might be faster. See "Encapsulating Mode Changes" for more details on using display lists to change such values as lighting conditions.
  
  

• Textures (Chapter 9 ). You might be able to maximize efficiency when defining textures by compiling them into a display list, since the hardware texture format might differ from the OpenGL format, and the conversion can be done at display-list compile time rather than during display.
  
  

• Polygon stipple patterns (Chapter 2 ).

Some of the commands to specify the properties listed here are context- sensitive, so you need to take this into account to ensure optimum performance. Most situations where this makes a difference involve pixel-transfer functions, lighting models, and texturing. Since all these topics haven't been introduced yet - they're covered in later chapters - the following example is a bit contrived. Although the specifics of this example are very unlikely, it illustrates an important principle that's discussed again in later chapters.

Imagine an implementation of OpenGL that's optimized to perform matrix transformations on vertices before storing them in a display list. If this were true, the time needed to perform the transformations would occur before rather than during display. Now suppose your code looked something like this:

glLoadMatrix(M); 
glNewList(1, GL_COMPILE); 
draw_some_geometric_objects(); 
glEndList();

The vertices in the objects would be compiled into the display list after having been transformed by matrix M. Suppose you invoke the display list as follows:

glLoadMatrix(N);
glCallList(1);

In this case, the geometric objects should be drawn using matrix N, but the data in the display list has been transformed by matrix M before it was stored. Thus, the display list has to save two copies of the original data (both the untransformed and the transformed vertices), thereby wasting memory. In addition, the vertices undergo two transformations when perhaps one would have sufficed. If instead you had defined the display list as follows:

glNewList(1, GL_COMPILE); 
glLoadMatrix(M); 
draw_some_geometry(); 
glEndList();

then no extra data would have to be stored, and full optimization would be possible. Of course, in this second case, you'd want to be sure that matrix M was really the transformation matrix you wanted.

Remember that display lists have some disadvantages. The buildCircle() example in Example 4-1 requires storage for at least 200 floating-point numbers, whereas the object code for the original drawCircle() routine (in immediate mode) is probably a lot smaller than that. Another disadvantage is the immutability of the contents of a display list. To optimize performance, an OpenGL display list can't be changed, and its contents can't be read.

OpenGL Programming Guide