Downsides of Display List?

OpenGL Development JOGL Development
#1

I’ve been fiddling around with a simple brute force grid as a learning tool for OpenGL operations, and today I tried putting all of the rendering commands into a display list. To my surprise the frame rate tripled. Usually when you get something good there is a price, so what’s the catch here? I presume that if OpenGL is doing all of the calculations ahead of time it must be storing them in RAM, so is that it? It’s eating up all sorts of memory? It would also seem that the geometry and all aspects related to it would have to remain static…

Anyway, if someone would like to toss out some negative aspects of display lists I would appreciate it :slight_smile:

#2

You are presuming correctly. When building an display list OpenGL records what you are doing and can pre-compute some stuff, and stores your operations in a more efficient manner. Although the reason for your speed up probably has more to do with the reduction of function calls. This is especially important with JOGL because of the expense in making a JNI call (one method/function call is being expanded into something more like 4 or 5). The only downside that I can think of is if your model changes quickly, then the overhead of rebuilding the display lists might negatively effect you. For most applications the memory cost is probably too trivial to worry about.

You might want to try vertex arrays and vertex buffer objects. They are faster then display lists, especially with vertex buffer objects, since they upload the geometry into the video card’s memory.

#3

Thanks for the speedy answer.

Would you say it’s true that most serious applications would use vertex arrays / VBO to the exclusion of Display Lists?

#4

The biggest downside to display lists is that they’re pretty much fixed - once you’ve created them theres no way to alter the geometry other than to rebuild it (costly). However if you’ve got static geometry then they’re about the fastest way to draw, and you can still tinker with translations and rotations to get a bit more flexibility with them.

Vertex arrays are not going to be faster than display lists, but they’re much easier to modify. Similarly, VBO’s should get you the best of both, but driver support is still somewhat patchy.

#5

Thanks Orangy, for the answer to my question. Since my current project currently consists of nothing but some static terrain, it sounds like display lists are the way to go.

Since it’s simple brute force, I think I can just use one the x and z values for one corner of the terrain, then compute all the rest of the verticies in a display list, and not have to store any of the data.

We’ll see how successful I am in a few days:)