Fast rendering performance is a critical element of any 3D or 2D application. With each release of a faster hardware or better software comes an increased level of expectation by end-users. While the world waits for the next better thing to come out, the developers keep busy trying to squeeze out the maximum out of what is currently available.

In this article, we explore one of the tools widely available in OpenGL today, which can offer significant rendering performance increases. Display lists, often overlooked, can provide significant rendering performance increases without requiring any major changes to your application. Below we will discuss what display lists are, how you would use them in your application and conclude with some performance and memory usage analysis when using display lists on different hardware configurations.

What are Display Lists?

There are basically two types of graphics systems; Immediate Mode and Retained Mode. With Immediate Mode systems, every time you want to draw your scene you need to repeat every function call that was required to initially create the scene. Examples of Immediate Mode systems include OpenGL, DirectX and X11. HOOPS/3dGS on the other hand is a Retained Mode system. With a Retained Mode system the geometry and attributes that define your scene are stored in a hierarchical database and after you initially create the scene you only need one function call (usually update) to have the scene redrawn. For drawing purposes a Retained Mode system will use an Immediate Mode system like OpenGL. Retained mode systems are typically easier to use and allow the system to implement behind-the-scenes optimizations that enable it to render the scene faster than an immediate mode system. Very few graphics applications do not have a database of some sort and consequently are considered Retained Mode systems. The primary downside of Retained Mode systems is that they come with a significantly larger memory footprint.

A display list is kind of an intermediate system. It is a group of OpenGL commands that are stored for later execution. It is analogous to a function or a subroutine in a programming paradigm. Since a display list caches the commands, it typically improves rendering performance specifically in the case where the same geometry is redrawn multiple times. Display lists are generally stored on video memory if available, but transparently swap to system memory if not. Instead, use the following warning: Display lists make an extra copy of geometry, so you should be careful not to run out of system memory.

When to use Display Lists?

Display Lists are extremely effective under certain situations. As an application developer, you are required to carefully understand when such situations exist to exploit the display lists. These situations are listed below.

• Invariable Geometry. Display lists are ideal in the situations where the actual geometry in the scene is not being edited. For example, a classic usage scenario is when the user is navigating through or examining an object in a scene. Since a display list is basically a cache of commands rather than a graphical database any modification will result in the display lists being re-generated which will result in a slight slowdown. When display lists are turned on in 3dGS, a display list is created for each tristrip of a Shell or Mesh in your scene graph and so there is no performance penalty if you add or remove new geometry to the scene or move geometry around the scene via modeling matrices. Also, as long as your coloring shells by changing the color in the segment it resides in then display lists will not be regenerated – this means highlighting works well with display lists. As mentioned above, editing the geometry (via HC_Edit_Shell(…)) directly as well as changing normals associated with a vertex requires the display lists to be regenerated which can be costly and should be avoided. For example, changing the rendermode from shaded to flat requires 3dGS to apply different normal data to the geometry which requires a display list regeneration.
• Performance more important than memory footprint. Since a display list is a cache of commands they result in some extra memory consumption. However this memory is taken from the memory on the graphics card, which is adequate for most visualization data.
• Consistent polygon handedness. To use display lists you must set a polygon handedness as otherwise the normals associated with specific vertices are continually being modified which results in a display list regeneration.

Note, regardless of whether you are using display list you should always try to set a polygon handedness. Setting a polygon handed can significantly reduce the rendering time by allowing 3dGS to do single sided lighting and possibly do backplane culling.

How to use Display Lists?

It is very easy to turn on (or off) display lists in HOOPS. Following is an example of turning on display lists.

HC_Open_Segment_By_Key(m_SceneKey);
HC_Set_Rendering_Options("display lists = on");
HC_Close_Segment();

m_SceneKey is key for the segment which includes your model. If you are using HOOPS/MVO, you could call following method.

HBaseView::SetDisplayListMode(DisplayListMode mode);

Performance Numbers

Following graph indicates the percentage differences in rendering speed and memory consumption of drawing the same scene with display lists versus without. So, for example, a green box value of 100 means that it was 100% faster than the non-display list path to draw that particular dataset. Similarly, a maroon box value of 19 means that the application took 19% more memory to draw that particular dataset when in the display list mode versus the regular non-display list mode.

Formula1 is a scene consisting of 765 segments and 399 shells with a total triangle count of 284,386.

Big Tube is a dataset consisting of 3 segments and 1 shells with a total triangle count of 802,814.

Large Assembly is a dataset consisting of 10392 segments and 16510 shells with a total triangle count of 728,574.

* Percentage increase/decrease in performance when using display lists
** Percentage increase/decrease in memory usage when using display lists