display lists vs vertex arrays

honkFactory
Unregistered
 
Post: #1
Howdy
I'm somewhat surprised that this topic has not yet been discussed here. I was just wondering what the pros and cons are over display lists and vertex array. In which situation should each of these be used?

Thanks
A.W.
Quote this message in a reply
Member
Posts: 351
Joined: 2002.04
Post: #2
One difference I could name is that you use Display Lists for geometry which doesn't change, or doesn't change often. But you can use Vertex Arrays for geometry which may change values. To give a real world example, in Slope Rider the trees use Display Lists but the geometry for the snowboarders (which animate) use Vertex Arrays.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
On 10.1, display lists aren't efficient.

On 10.2, display lists and vertex array objects are essentially the same beast.

As monteboyd said, use arrays (perhaps with VAR) for dynamic data, and either VAO or display lists for static data.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #4
Display lists are compiled into VRAM, and hence the CPU has practically nothing to do when a display list is called, which is a good thing. But, once a display list is compiled, it cannot be modified, and only a few commands can be used in the lists.

Vertex arrays, on the other hand, are excellent, as previously pointed out, for dynamic data. Vertex arrays use a little more CPU, but use DMA transfers from memory, which means it uses still very little CPU compared to ordinary glVertex4f() and the likes.

I prefer to use vertex arrays, because I like having control over my drawing. If you plan to have a lot of things which modify how things are drawn, a vertex array is better. With nvidia chips, I believe the vertex arrays can be put into VRAM for a further speedup.

I suggest you read up on OpenGL client and server states, it might help understand the limitations of display lists.

- D.G
Quote this message in a reply
Member
Posts: 177
Joined: 2002.08
Post: #5
Another thing about vertex arrays is that you have to make the decision to use them early on, because they have a huge influence on your low-level data structures.
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #6
as for displaylists, don't forget that you can use transform matricies to move/scale/rotate/sheer them. If this is all you need to do then, they're great. Smile

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Member
Posts: 148
Joined: 2003.03
Post: #7
I'm using vertex arrays to display and animate Meshwork models. For each bone in the model, there is an array of triangles which, after the appropriate translate/rotate/push|pop matrix, are submitted using glDrawElements. I'm wondering if I should:


A) keep it the way it is

B) pre-compile the triangles for each bone into a display list using:

B1) glDrawElements, and then replace the runtime glDrawElements with a call to glCallLists

B2) glBegin, glVertex, etc.., and then " " " " " " " " "


For A, I get 310-330 fps rendering a lighted, non-textured, 4 color (colors submitted using color array) mesh with approx. 750 triangles at full screen (215-230 in window).

For B1, I get 540-570 fps rendering a lighted, non-textured, non-colored (no color array submitted) mesh with approx. 750 triangles at full screen. 530-540 fps when color arrays are submitted.

One begins to wonder, for the drastic speed improvement with B1, are there any drawbacks that I don't see headed my way?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
If you're changing your vertex arrays every frame (as in, the model is animating), I'd expect to see the plain vertex array route faster than display lists.

If you can do the skinning in a vertex program and submit unmodified arrays each frame, then display lists will often be faster.

There is a huge overhead to glCallList(s). I've found it's not worth submitting less than a few thousand triangles in a list.

If you are changing your vertex array every frame, APPLE_vertex_array_range and APPLE_fence are your fastest choices at the moment, but ARB_vertex_buffer object will also be a good bet once Apple implements it.
Quote this message in a reply
Member
Posts: 116
Joined: 2002.04
Post: #9
Quote:Originally posted by OneSadCookie
If you are changing your vertex array every frame, APPLE_vertex_array_range and APPLE_fence are your fastest choices at the moment, but ARB_vertex_buffer object will also be a good bet once Apple implements it.


No doubt, VAR is the fastest path currently.

It appears to me that ARB_vertex_buffer is what VAR should have been originally. It will be nice to have a cleaner spec without so many variations.

Wade
Quote this message in a reply
kberg
Unregistered
 
Post: #10
What if I'm drawing a few textured quads? I haven't played with vertex arrays yet, but can a single vertex array bind to different textures?

OSC: the overhead to glCallLists, is it really that bad? If so my use of display lists may actually be hurting performance, since a single display list may contain 100 -> 150 textured quads at most.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #11
Quote:What if I'm drawing a few textured quads? I haven't played with vertex arrays yet, but can a single vertex array bind to different textures?

No, it can't. In this case, a display list may well be you best bet, since it can store all the primitives as well as the texture state changes on the card. Don't know if it does, though Smile

Quote:OSC: the overhead to glCallLists, is it really that bad? If so my use of display lists may actually be hurting performance, since a single display list may contain 100 -> 150 textured quads at most.


I would imagine that display lists are hurting your performance in that case. Profile and see, of course.
Quote this message in a reply
kberg
Unregistered
 
Post: #12
ah geez, Now that I think of it, all my font's are stored and called as an array of display lists (textured quads) too... This might be a huge performance killer if what you say is true Blink
Quote this message in a reply
Member
Posts: 177
Joined: 2002.08
Post: #13
Quote:Originally posted by OneSadCookie
No, it can't.


Some clarification... Vertex arrays obey the same state-changing rules as everything else, which means that during primitive specification (betwen glBegin and glEnd) you cannot change the texture state. Therefore, glDrawArrays, glDrawElements, and glDrawRangeElements, which contain implicit calls to these functions, can only draw with one texture at a time. However, nothing stops you from carving up the vertex array into regions of seperate texture and drawing them seperately (i.e. specify pointers once, call glDrawElements several times with different textures and indices). You can get even more control with glArrayElement, since you get explicit control of glBegin/End, but that function is the least efficient of the bunch since it's called once per vertex.

Also remember that if you put vertex array operations into a display list, the list will not be updated if you change the pointers or the contents of the arrays.
Quote this message in a reply
henryj
Unregistered
 
Post: #14
Couple of things...

Don't assume a path is slow until you have tested it.

Display lists get written into VRAM. This is the reason that they are fast but also the reason that you shouldn't change them (this is a simplification). Storing vertex arrays in VRAM, which you can do in 10.2, will have the same effect. They will be fast but will be slow to change.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  ? Export Vertex Arrays from Gfx App ? Elphaba 2 2,831 Jun 11, 2009 12:39 PM
Last Post: Elphaba
  Display Lists and Obj. File Loader Problems merrill541 0 1,891 Oct 17, 2008 06:42 PM
Last Post: merrill541
  VBOs and Vertex Arrays in OpenGL not working Talyn 6 6,211 Jul 8, 2008 01:14 PM
Last Post: Fenris
  Display Lists or Vertex Arrays with texturing seven 6 3,702 Oct 17, 2005 09:24 AM
Last Post: seven
  Slowing Frame Rates and Display Lists Nick 4 2,953 Mar 27, 2005 06:08 AM
Last Post: wadesworld