There is already an optimization used to auto-detect when geometries don’t change (say, if after 10 frames nothing has changed, that part of the branch graph is optimized)
It would be nice to have the same feature with display lists : sometimes models just don’t move for a while, and they could be promoted to DL (until they start moving again).
This adaptative feature could also be used to nest static DL when the whole group doesn’t change for a while…
My 2cents comments
Lilian 
I already talked about this above. I’ll do that. Thanks for the comment ;).
Yes. cool, too.
Ok, so this was my 1 cent… ;D
By the way I have a problem with your current display list implementation : I have about 200 shape3D which are actually animation frames. They are all sharedCopied for each unit instance and stored in a Vector and I add them to the scenegraph when it’s their turn to be displayed.
The problem with display lists is that (I suppose) one display lists per shape is created… and I would instead one per geometry… With the current implementation, memory usage go crazy and performance is worse than without display lists. See ?
c_lilian, great to see you again ! 
What are you currently up to ? :
Really ? How is it implemented.
Hi Amos, I’m working on Jack Flowers… currently on the “donkey kong” bonus level and boss fights…
Lilian
Yes, I see. I’ll change that on the weekend. OK?
OK. Have anything recently annoyed you in Xith3D and you would like to get it changed ? (Question is also for others users).
OK. How do you think you’re gonna implement it ?
Well, since each Shape3D has exactly one Geometry, the DisplayList doesn’t need to be switched to the Geometry. But the RenderPeer must check, if it is a shared copy and create or use the DL depending on this check.
Well, I have stopped updating from CVS since Xith lost its 1.4 compatiblity (that stops at least 50% mac users from using it) so the changes don’t bother me…
I’ll try to get back to the main branch later, once my game is released.
Lilian
I think I remember when the discussion about switching to Java 1.5 was made, someone said, that java 1.5 has mac support, too. I’m too lazy to search the appropriate thread. But please check that. I think it won’t be a barrier anymore.
Marvin
java 5 is for mac os X 10.4, and this version is used by half the mac user base… stats grow up slowly but this will take years to get rid of OS X 10.3
Lilian
Well, why not “retroweave” ?? ;D http://retroweaver.sourceforge.net/ It seems “magical”.
Once you succeded using that to deploy with Xith3D-Java1.4 then you’d just write a small doc so everyone can seemlessly do so.
And, of course, you would benefit of all the improvements that are currently added to the main branch.
What’d you think of that ?
I won’t change my engine at less than 3 months of the official release of my first title…
I’ll evaluate your changes for the next game or for JF after the first release and see if retroveaver suits my needs (of course I’ll share the evaluation with JGO)
Lilian
Hum, yeah, sure, “tu es plus raisonnable que moI”… I always tend to change for newer versions of libs, whatever release schedule I do have.