Does it make sense to include texture-unit enabling/disabling into a display list? Or should I enable/disable texture-units before I start a new display list?
In other words: How are texture-unit states handled in a display list? Is a display list’s result changed, if I disable a texture-unit before a subsequent run, that was enabled at creation time of this display list?
Marvin
OpenGL is a state-machine.
When you don’t include the enable/disable in the displaylist, the displaylist will execute with the texture-units that are enabled/disabled that the moment of executing.
As riven said, enable/disable outside of the DL, makes things much easier to manage.
But why are you still using Display Lists? In OGL 3, they are going to be emulated on top of VBOs…
DP 
ok. Good to know.
Well, my experience says, that VBOs and DisplayLists are different in execution time. One time VBOs are faster and another time DLs are. I don’t know, what this depends on. So I want to keep them both until this changes.
Marvin
It’s genarlly a good idea to put comamnds that change state into a DisplayList. That way they can be read/executed in the GPU, instead of having I/O with the CPU
Good point. I never considered this to be a too big problem. I always thought, they were negligibly small overhead compared to real data transfer.
Though with VBOs I don’t have a change to give away state changes to the GPU, do I?
Marvin
How else are you going to set the texture without changing state?
I dont believe that adding state changes to DL makes that much difference since the driver typically does a memory sync on such calls anyways which would require readback from the GPU. I do realise that this is a driver specific thing, but both NV and ATI seem to do it.
DP