I was playing around with some of Cyrille's pmpd patches and noticed that he commented on several of them needing lots of CPU to run. I quickly figured out that it was the sphere object that ate most of the CPU, and I had already made a note to fix this after Johannes rewrote the object. The big problem is that sphere calculates each and every vertex each and every pass even though most of the time the geometry is static. The quick fix I just committed to CVS only calculates the geometry when a parameter changes (slices, drawing style, etc). The result is at least a 3X improvement in performance, and most of the pmpd stuff runs ok now on my Powerbook.
Now, this is all fine and well, but the object is still in immediate mode and thus quite inefficient. I thought about creating a display list inside the sphere object, but that has two drawbacks. FIrst, there is considerable overhead compiling a list and uploading it. Second, it would waste a lot of VRAM for something like Cyrille's patches. The idea I have is to try and move as much stuff out of immediate (or idiot) mode as possible and try and create a system that really scales well for GEM. I think we could have a type of client and server using display lists that would function like this:
[GemCreateList name geo arg1 arg2]
[GemCallList name]
The first object would create a display list with a given name, and build a list with the desired geo inside the list. The second object would issue a glCallList() with that given name wherever the user needs that geo. This should be very fast and extremely efficient for large scale patches. It might even help GEM gain a bit of dynamism that it currently lacks.
cgc