Performance of Display Lists

I have a static mesh of quads and tris. To speed up my performance i put them into a Display List. It looks like following:
modelList = glGenLists(1);
if (modelList != 0) {
glNewList (modelList, GL_COMPILE);
glEnableClientState (GL_COLOR_ARRAY);
glEnableClientState (GL_VERTEX_ARRAY);
glVertexPointer (3, GL_FLOAT, 0, vertices);
glDrawElements (GL_QUADS, numQuads4, GL_UNSIGNED_INT, elements_quad);
glDrawElements (GL_TRIANGLES, numTrias
3, GL_UNSIGNED_INT, elements_tria);
It increases my perfomrance for models with about 50.000 elements quite good. But if my modelsize is about 300.000 elements there is nearly no difference. Is there a size limit or did i make a mistake?

300,000 elements per frame is pretty large for most graphics cards. At 60fps, that’s 18 million PPS, which is outside the useable range of most graphics cards. And, even on a good GeForce or Radeon, you’d have to use VAR/VAO to get even close to that.

I do not see a sense on your code, cause after a display list is created, it resides with the server, so the server can’t rely on the client for any information related to the display list.

glVertexPoiner and stuff depends on client state. It only make sense to put glDrawElements in a list, cause data is going to be send to the server state, which construct primitives from elements in the enabled arrays.

It’s totally valid to put the code like this, only the display-listable functions compile stuff into the list, the client state stuff like array pointers are executed immediately.
It just would have been more elegant to put only the glDrawElement calls into the list.

I would try keep the number of vertices in each glDrawElements call below 2^16.

If you’re able to construct strips from your geometry instead of independent primitives, that would gain a lot.

Would it make any sense to put just the glDrawElements commands in the display list?Would it speed thins up?I mean there’s not much to compile into the list.Or is the data in the arrays actually sent to the server at compile-time?If that is the point then there would be no need to use gl*Pointer() before calling the list or keep the arrays in memory.Is any of the above correct?

> Would it make any sense to put just the glDrawElements commands in the display list?
Yes, if the content of the array doesn’t change.

> If that is the point then there would be no need to use gl*Pointer()

My vertex data is completly static. I made a test today, where i could increase the frames, only by using glVertex3f! If i add color in the Display list it slows down a lot. The next step is to split up into more display lists. Is there a reasonable method for this?

What kind of data do you render? Terrain? …?

I do only show lines or Flat shaded lines. Sometimes i display textures with colors.


I would like to add a few questions here:
What does the card do exactly to optimize your call to glDrawElements in your display list?
Would it be better to use GL_QUADS, or is it better to use GL_TRIANGLES (vertex sharing of course)


It doesn’t optimize the call to glDrawElements.It just executes the call and,instead of drawing the data, it caches it on the server in a (hopefully) HW friendly way.Anyway whether you called glDrawElements or used immediate mode,it wouldn’t make any difference.Thats why you can free the arrays afterwards,the data is allready at the server.I’m not sure about the second one but it shouldn’t have much to do w/ display lists,rather with wehter its generally better to use QUADS or TRIANGLES.But since opengl tesselates everything to tris before rendering(doesn’t it?) it shouldn’t make a difference since it propably will be tesselated during list compilation.

Yes, but the issue is

with GL_QUADS, you have x number of vertices, and X number of indices for glDrawElements

with GL_TRIANGLES, you have x number of vertices, and Y number of vertices for glDrawElements.

So X < Y, right?

GL_QUADS would be better or the driver will break them up in TRIANGLES and redo your indices accordingly.

Let’s forget about display lists for a moment if it doesnt make a difference.