Description
Is your feature request related to a problem? Please describe.
Right now the fundamental drawing unit of Pygame GUI is the element. Drawing is done by looping through each element in order of it's layer and then blitting it to whatever surface is passed to draw_ui().
It occurs to me that a lot of the time UIs are fairly static, unless parts are being moved, animated or otherwise interacted with a lot of the time many UIs are just a static image atop a moving game world.
Thus we could, perhaps, consider a redesign for the drawing that looks something like:
- Draw everything in the UI to a large transparent surface and then blit that onto whatever surface is passed to draw_UI (effectively this would be the 'image' variable of the root container).
- Treat containers as a fundamental part of the drawing UI. Give each one an image and perhaps a layered sprite group. Let elements send a message to their container that they have changed their blitting parameters in some way and then that would trigger a redraw/reblitting of the container and, crucially, any overlapped containers.
- In theory this would mean a large drop in average blitting at a cost of storing an additional surface for each container in memory. You would also get more spiky UI performance with small blips (but no worse than the current drawing) each time you interacted with something.
Describe the solution you'd like
Due to the memory vs speed trade-offs involved I'd probably try and implement this solution as an option in the UI manager, at least at first. See if it is a useful or popular change.
We may need more options in general for the UI system to trade-off memory usage (see caching) and speed.
Describe alternatives you've considered
Changing nothing, mainly because there haven't been that many complaints about speed yet and I'm wary of premature optimisation.