hai friend,
I have one doubt regarding to the glGenList()…In this how many list we can generate at a time…
Ex: GLuint m_List;
And with out delete the list can i mode modify the data in the list.
As many as you can, until it generates an error.
However having 100+ of DL is not really useful.
Use gLGetError() frequently.
No you can not modify a DL. Delete and recompile.
DL are fast because they inflexible. If you want geometry flexibility, go for VBO instead.
In my scenes there are from few hundreds to few thousands DLs, and they work fine. In fact, much faster than VBOs. Of course, DLs cannot be modified. It is more expensive to delete and recreate DL than refill VBO buffer, but putting buildings or terrain-patches into DLs can be very effective.
Aleksandar, do you have 1000 DL used in a single frame ? Or more like a pool, with low percentage actually used each frame ?
And on which video cards did you benchmark the improvements over VBO ?
IIRC, At some point (particular driver version) DL codepath was so optimized compared to vbo one on nvidia hw that it was faster for static meshes. I don’t know if it still the case, but IMHO, it does not matter, DL are only a little subset of what VBO can provide (speaking in terms of data management).
I have carried out many experiments on various video cards since 2005 (MX440, Radeon 9200, i810, GF7800, Radeon x850 Pro, GF8600GT, GF8800GTX, etc.) DLs were always faster than VBOs. Sometimes significantly, sometimes barely noticeable…
Currently, I program on my laptop with GF8600M GT. Although my desktop has a more powerful GPU, GF8600 is sufficient for everything I have tried (except measuring performance 
).
To ilustrate the whole story, I have posted a screen-shot from our GIS application. It is a part of the city with buildings colored with solid colors and switched-off fog effects. Buildings can be very complex Collada object, but in this case I have included just simple objects…
http://sites.google.com/site/opengltutorialsbyaks/events/_draft_post/VR-1_resize.jpg?attredirects=0
The total number of DLs in this scene is 6233. Screen-shot is taken form GX600 laptop (with turbo taster switched off) and GF8600M GT video card. Time to render the scene is 19.3ms (51.8fps). I have to admit that some of DLs are very simple, and that I’m using DLs almost like VBOs (just to store data, and not transformations). The result would probably be different if I had DLs with thousands of vertices. I just wanted to say that number of DLs is not so important and doesn’t have significant performance issues.
On many places (sites, forums, etc.) I have read that texture binding is an expensive operation. In the following picture you can see a scene with 1089 texture bindings in just one frame (all buildings are excluded, the scene contains only a huge terrain divided into more than 1k DLs). The scene is drawn even without view-frustum culling.
http://sites.google.com/site/opengltutorialsbyaks/events/vr-1picture/VR-2.JPG?attredirects=0
Rendering time: 3.7 ms (~270fps)
Test machine: MSI GX600 laptop with GF8600M GT
I’ll try to reduce number of textures to 5 for the whole terrain, and also the texture bindings to the same amount using clipmaps. But, I really doubt that the frame-rate will be much greater. Nevertheless, I’ll publish my results. Maybe I’m wrong, but we will find out soon.
The point is… during my researches I have found that the main bottleneck is data generation and GPU feeding, and not (reasonable) amount of data, number of DLs or bindings. Hm… I have to try NVIDIA’s bindless graphics before I confirm the last statement.