[font="arial, verdana, tahoma, sans-serif"] [/font]

The problem is not with display lists. Display lists are just batches of instructions. The problem is that you are saturating the communications with your card on trivialities. You are flooding the bus between your CPU and GPU by re-transmitting your data in tiny pieces every frame. Dump all of it to the card up front. Let it live on the video card memory. Use a shader on the video card to process it. If you can't dump it all at once, create a really big interleaved array and dump that to the video card every frame. At least then you are using a single transfer rather than a ton of tiny stored commands.[/quote]

I think I'm either misunderstanding you, or you're misunderstanding me.

When the terrain block is generated, it creates a display list and stores that display list ID in a local variable. At each frame, I'm only calling glCallList(display_list) for each terrain block, which is about 9-15 blocks at any given time. I'm not re-generating the display list at every frame; that would be silly.

[font="arial, verdana, tahoma, sans-serif"] [/font]

The problem is not with display lists. Display lists are just batches of instructions. The problem is that you are saturating the communications with your card on trivialities. You are flooding the bus between your CPU and GPU by re-transmitting your data in tiny pieces every frame. Dump all of it to the card up front. Let it live on the video card memory. Use a shader on the video card to process it. If you can't dump it all at once, create a really big interleaved array and dump that to the video card every frame. At least then you are using a single transfer rather than a ton of tiny stored commands.

I think I'm either misunderstanding you, or you're misunderstanding me.

When the terrain block is generated, it creates a display list and stores that display list ID in a local variable. At each frame, I'm only calling glCallList(display_list) for each terrain block, which is about 9-15 blocks at any given time. I'm not re-generating the display list at every frame; that would be silly.
[/quote]

Ah, I think I see the misunderstanding.

Using a display list is not free. It is only specified to probably not be slower than immediate mode.

It is unspecified where display lists are placed. While they *MIGHT* be placed on the card, there is no requirement to do so.

You are correct that there is a tiny performance benefit by making the list up front. The drivers will pre-process them and compress them. But that's all they do.

Neither ATI nor NVidia have publicly stated what they do with lists. So people have monitored bus transfers on drivers from NVidia and ATI in the past and found that they keep them in main memory in an arbitrary format. They generate and compress the command stream, but still must re-transmit it on every use. There is only minimal performance improvement over redrawing everything yourself.

You are using the worst case form of display lists -- a bunch of tiny lists. There is overhead associated with each one, you should prefer one large display list over multiple tiny lists.

Finally display lists are depricated in GL3.0 The replacement is to move it over to the card and do it in the way mentioned above, which has been the preferred way of doing it for over a decade.

It would appear that drawing one big display list is slower than drawing several smaller ones. Is this understanding correct?

Display lists have pretty much been replaced with static vertex buffer objects (VBOs created with GL_STATIC_READ usage), and in general when using these the more data/meshes you put into a single object the better performance. Ideally, all vertices used to generate the scene should be placed in a single object and drawn with a single call so that the graphics card can plow right through them.

BTW (edit): If you think your code is correctly implemented with respect to the OpenGL guidelines and you still get a really poor performance there is a chance you are overlooking something in the WGL documentation (assuming you are developing for Windows). Personally I remember getting a really low frame-rate some time ago because I missed some detail about multi-threaded applications.

GL makes so guarantees as to the location of VBOs either, and a given implementation may store them in system memory. Highly unlikely of course.

But then again, GL doesn't make any guarantee that data in display lists are not stored in system memory, either.

Worth noting

I got a pretty good frame-rate on a rather old computer (from 2005) with 360,000 textured polygons on the screen using VBOs, so "worth nothing" is perhaps a little harsh judgement.