tags:

views:

120

answers:

3

Hi!

I'm new to OpenGL. I have written a programm before getting to know OpenGL display lists. By now, it's pretty difficult to exploit them as my code contains many not 'gl' lines everywhere in between. So I'm curious how much I've lost in performance..

+4  A: 

It depends, for static geometry, it can help quite a lot, but display lists are being deprecated in favor of VBOs (vertex buffer objects) and similar techniques that allow you to upload geometry data to the card once then just re-issue draw calls that use that data.

Display-lists (which was a nice idea in OpenGL 1.0) have turned out to be difficult to implement correctly in all corner cases, and are being phased out for more straightforward approaches.

However, if all you cache are geometry data, then by all means, lists are ok. But VBOs are the future so I'd suggest to learn those.

Marcus Lindblom
+1  A: 

Call lists are boosting performance. If your users graphics card has enough memory, and supports Call lists (most of them):

There are several "performance bottlenecks", of which one of them is the pushing speed of data to the graphics card. When you call a OpenGL function, it will either calculate on the CPU or on the GPU (graphics card's processor). The GPU is optimized for graphics operations, but, the CPU must send it's data over to the GPU. This requires a lot of time.

If you use call lists; the data is sent (prematurely) to the GPU, if possible. Then when you call a call list, the CPU won't have to push data to the GPU.

Huge performance boost if you use them.

Pindatjuh
what data ? The only data that CallList usually pushes to GPU is vertex data. And only if you do your incantations right, too. And, as Marcus said, you already have ways to send _that_ data to the GPU with VBOs. If they were that magic, they would not be deprecated
Bahbar
+1  A: 

Corner case: If you plan to run your app remotely over GLX then display lists can be a huge win because "pushing to the card" involves a costly libgl->network->xserver->libgl trip.

Nathan Kidd
That's unlikely, but thanks, I'll keep it in mind.
Alex