I am running into more and more performance issues with my TreeGUI. I think this is due to number of geometry on screen (can be as high as 200 geom nodes) basically representing icons and second alpha over draw. I have many icons overlapping icons.
Obvious solution is merge more stuff, flatten or similar methods but that fails to work because the GUI is mostly dynamic. My last attempt is to draw stuff already merged, but that is proving harder and harder. I am at a loss for other methods of speeding this up.
Maybe the solution is to do it completely different way and draw bitmaps on the CPU composed of many icons and send them over to the GPU basically as huge on screen texture. This way i would not be limited by the GPU inability to draw more then ~300 geom nodes (which i need for in game graphics)
I have tried a similar approach with pygame but that was way too slow.
This is a classic 3-D engine problem: the graphics hardware really wants things to be flattenened together and sent all at once, but most interesting graphics problems want things to be dynamic and, therefore, independent.
Painting things into one big bitmap is a solution, but it’s the same kind of solution as flattening: it just pre-bakes all of your gui into one big bitmap. If you’re going to be painting it, you might as well flatten it instead; it’s easier and probably faster.
One solution to make the flattening easier is to keep an offscreen copy of all of your objects in their pure, unflattened state. Then, when you need to change something, make a change to the pure scene, copy it, and flatten it. Attach the flattened copy to render2d.
If you’re clever, you can keep the part of the gui that the user is currently interacting with out of the flattened scene, so you can keep that part live and easier to update.
Traditional 2-D graphics are done by painting pixels into a framebuffer, in which complexity of graphics has zero impact on frame rate.
Traditional 3-D graphics are done by sending a series of graphics commands to the graphics engine repeatedly every frame, in which the complexity of graphics has a huge impact on frame rate.
This has nothing to do with whether you’re actually drawing 2-D or 3-D graphics, of course. You can use a 3-D engine like Panda to draw 2-D graphics, but it does it using the traditional 3-D graphics engine pipeline (and this is the only way to draw 2-D graphics on top of a 3-D scene).
If all you want is a 2-D scene, you can use SDL or pygame without messing with Panda and you don’t have to deal with these problems. (You have other sets of problems, of course.)