can anyone explain why display List renders much faster?

I know there is traffic on vertex array for rendering each time. Is it because there is no traffic (data transmission from CPU to GPU) for display list, which makes the rendering so fast? seems overhead on function call is not the reason; there is also little function call overhead on the method of vertex array.

========================
benchmark report

Render Method: Immediate Mode
Benchmark Initiated - Standby…

– doBenchmark Report –
Render Method: Immediate Mode
Frames Rendered: 1000
Sphere Resolution: 500
Primitive Used: GL_TRIANGLE_STRIP
Elapsed Time: 18.702999s
Frames Per Second: 53.467361

Render Method: Vertex Array
Benchmark Initiated - Standby…

– doBenchmark Report –
Render Method: Vertex Array
Frames Rendered: 1000
Sphere Resolution: 500
Primitive Used: GL_TRIANGLE_STRIP
Elapsed Time: 10.453000s
Frames Per Second: 95.666315

Render Method: Display List
Benchmark Initiated - Standby…

– doBenchmark Report –
Render Method: Display List
Frames Rendered: 1000
Sphere Resolution: 500
Primitive Used: GL_TRIANGLE_STRIP
Elapsed Time: 1.859000s
Frames Per Second: 537.923624

Use VBOs. You should get faster performance than standard vertex arrays.

When you create a display list, you compute them. So, all the transformation and data are generally stored in the graphic card. This is why this is very faster than normal VA. But now display lists are slower than the ‘faster meshes drawers’.

Try to see CVA (, VAR) and VBO, you’ll certainly be faster than with display lists.

On nv quadros, display lists give the same peformance as VBO - but, get this, only if they’re compiled using immediate mode!

DLs give super fast (thrashes everything else, VBOs whatever) drawing stuff thats not onscreen, yes i know dont draw things that aint onscreen :slight_smile: but it seems as if theyre sticking something else in there as well when they construct the DL perhaps a BB for the DL

DLs give super fast (thrashes everything else, VBOs whatever) drawing stuff thats not onscreen, yes i know dont draw things that aint onscreen :slight_smile: but it seems as if theyre sticking something else in there as well when they construct the DL perhaps a BB for the DL
That’s actually a highly dangerous thing to do, given modern vertex shaders. Something that seems like it should be off-screen may actually be on-screen once the shader gets to it.

Presumably, though, they turn this optimization off when vertex shaders are active.

they turn this optimization off when vertex shaders are active.
prolly just like early out with depth testing, as long as u dont write to depth in the shader youre alright.
im not 100% sure this is what they do (nvidia card) but i was testing a couple of months ago, seeing how many meshes i could draw in 5 seconds with various methods. ild start drawing on the left of the screen and keep on drawing meshes upwards to the top of the screen then **** over to the right + repeat (minimize overdraw) anyways it seemed as soon as the right side of the screen was reached the DLs went through the roof literally billions of tris a second, something the cards not capable of.

(edit)on drawing meshes upwards to the top of the screen then **** over (what did i write?), move over? hmmm perhaps shift over :slight_smile: + my freudian friend dropped the f

Originally posted by zed:
DLs give super fast (thrashes everything else, VBOs whatever) drawing stuff thats not onscreen
I’ve seen that too. It feels like they do a quick check on what the dlist contains and what the state is and do bbox culling if possible. Nice feature for all those stupid CAD apps that don’t do any culling themselves… :wink: