   Display lists and vertex arrays again
  Greetings all,I posted a question about display lists vs. vertex arrays awhile ago (and it sparked a great discussion   ), and I finally got of my duff and experimented a bit.As a super-extreme example, I rendered about 500,000 quads by brute force, meaning about 500,000 calls to glBegin(GL_QUADS) and glEnd();.  I got about 3 or 4 fps on a Pentium M 1.6Ghz laptop with a 32Meg video card.I then stuck all of those calls inside a glNewList call and rendered only the list.  I got about a 25% increase in rendering speed.  I was expecting quite a bit more than that.  I tried reducing the number of calls to glBegin(GL_QUADS) and glEnd() by listing multiple quads, but it didn''t speed up performance, only the time it took to compile the list (took almost no time at all!)Then I threw in vertex arrays inside a display list.  The increase in performance was about 600% over the display lists with the glBegin and glEnd calls.That about what I should have expected?   Love means nothing to a tennis playerMy nothing-to-write-home-about OpenGL webpage. (please pardon the popups!)
  Just wondering could you do this with only vertex arrays (no display list) and post the numbers aswell?I myself notice vertex arrays are much better for preformance than display lists. ;  I''m pretty sure that half a million quads is not going to make an effective display list.Aren''t display lists generaly optimised for much smaller data sets?Also, it''s not a very fair comparison if you include half a million "begin" and "ends" inside your display list.  I would have guessed that any video driver worth it''s salt would have optimised those out, but it''d still be worth trying with only one set of begin and ends and see how that compares to the vertex array.Also, what kind of video card do you have? Inquiring minds want to know! ;  As AndyL said I think that in your example the thousand of glBegin and glEnd calls are responsible for the low fps. Try to use only one glBegin and one glEnd and benchmark it.   --------------------------------------------------------There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.There is another theory which states that this has already happened... ;  My video card is an ATI Mobility Radeon 9000 with 32Megs of video memory.  It''s the card that comes with the Dell Latitude D600 by default.  Processor is Pentium M 1.6Ghz, 512Meg RAM.Corrail and AndyL:  I ran the test once with 500,000 glBegin and glEnds inside the display list, and then ran it with 8 glBegin and glEnds inside the display list and noticed no difference in performance.  This plays into the theory that a good video card optimizes those out.  It also plays into that theory that with the 500,000 begin and end calls it took a long time to compile the display list, but with only 8 it took almost no time.Just for the fun of it, I tried it without the display lists both ways.  500,000 begin and end calls ran about 20% slower than it ran with 8 begin and end calls with 60,000 polygons each (yes, I know that''s 480,000 - I was guesstimating   ).I''ll try the vertex arrays without the display lists when I have a chance.   Love means nothing to a tennis playerMy nothing-to-write-home-about OpenGL webpage. (please pardon the popups!);  Vertex Arrays only will be alot slower than Dislplay Lists with Vertex Arrays. This is especially true with new drivers as they try to store Vertex Arrays in DLists in Video Memory, and you tend to get the same performance as VBOs. You should only use Vertex Arrays alone if your data is dynamic. ;  I ran it as vertex arrays only and it seems to confirm GamerSg''s assertion.  It was 75% slower as vertex arrays only than as vertex arrays within a display list.Here''s a weird one - my laptop has a 2000/XP dual boot and the experiment, no matter what configuration I ran it in, was 3 times slower on 2000 than on XP!  Now THAT is weird!!!!!  Is my computer possessed or is there a logical explanation for that???   Love means nothing to a tennis playerMy nothing-to-write-home-about OpenGL webpage. (please pardon the popups!);  It looks like trial and error is really the only way to figure out the best combination of stuff for a given engine, and maybe even a given situation within the engine.For example, it''s kind of a pain that you can''t frustumcull parts of a display list.In the current version of my engine, the modelling tool (second demo down on my site) allows users to create prisms, rectangles, cylinders and spheres.  Since I haven''t implemented per-pixel lighting yet, I split up the rectangles and prisms into slices and stacks the way glu splits up cylinders and spheres.  The 480,000 polygons I rendered in the test example are 8 prisms, 100 slices and 100 stacks, so 10000 polygons per side x 6 sides x 8 prisms = 480,000.I was even thinking about adding not only frustum culling, but backface culling - if a facing of a rectprism is facing away from the camera, don''t even send it the rendering pipeline.For "maximum efficiency" this approach would entail 6 display lists per prism!Well, I''m gonna try it.  I''m gonna experiment, I''m gonna try it.  I''m gonna do it.  Whichever gives me the best performance, I''m gonna go with it.   Love means nothing to a tennis playerMy nothing-to-write-home-about OpenGL webpage. (please pardon the popups!)