Pretty common things, the problem is I don't have a great deal of love for the ones which exist, which is... ya know, a tad annoying, because that means my brain gets itchy and I find myself struck with a need to write one... bah.
Now, I do need one for my final year project, nothing overly complicated really; some way of doing a selection between techniques and fiddling with numbers. Worse comes to worse for that I can rig something with a control panel being on screen 2 while it displays the output on screen 1 (which come final presentation day will live on the big screen behind me).
However, that's the future, and I want to deal with now...
Of late, as you might have guessed from my praise singing, I've been using Vista, and one of the things Vista has going for it is the new Aero system and that every window is rendered to it's own texture. I like this system, so I've been considering how to do my own version [grin]
The biggest problem is, at what level do we stop rendering to textures?
My inital thoughts on this was at the panel level, so each panel has it's own texture (or sub-texture, I'll come back to this) and everyone renders into it when something changes.
That last bit is important; frankly in a game situation (heck, any situation) large parts of the display never change for extended periods of time, so re-rendering them is somewhat pointless imo. You could even do dirty rectangles on the textures, so if you had a panel with two buttons and a text box on it, when a button is pushed you only clear that button and re-render it.
Sub-textures where mentioned above; while a texture per-panel might work it could also destory gpu rendering speed due to texture swaps and small batches; now granted the gui shouldn't take that much power, but still.
So, another problem is how do we allocate and pack textures together when required? I'm still working on this; configurable as min/max sizes is one idea, with certain elements getting their own dynamic texture (cached?), such as pop-up boxes. The other being grab a texture of the biggest size and pack until you cant fit any more in and then grab another texture and so on.
This would allow for VBO rendering of the final GUI with no problems. Texture atlas-ing could be extended to use 3D textures on newer hardware (no filtering, what with 2D elements generally being screen aligned anyways) and to texture arrays on D3D10 capable hardware (once I have some of course, heh), which would allow for one draw call to draw the whole GUI with no problems.
How would the updates work is another issue;
My current thoughts on this would be if a child component's visual state changes in some way it informs it's parent that it needs to be rendered again and then, when asked to update, the parent can make it redraw it's self before signing off on the current state being ok.
Text rendering is my final problem;
I've successfull used Freetype 2 to render to a texture for FPS and Update per second display in a previous project/app, so I'm happy with it and it's speed (given the texture caching talked about above it becomes even less of an issue), it's just a matter of working out how to fit it into the over all project design.
Texture allocation is handled by another subsystem; the idea being that the GUI controller expects a texture type with a certain interface to work with (probably bind, width and height at the least), beyond that it'll be templated for any texture type.
The GUI controller then handles the setup for each GUI panel with-regards to setting up things such as Orthographic projects, render targets and the like. Any slipping should probably be handled at a per-component level.
So, that's my current thoughts on things, arch. wise; if anyone wants to chime in it would be nice [smile]
I might try and get down to some class design thursday night once I'm done with college as this is kinda intergral for my project (don't you love how I justify this stuff to myself? heh [grin]).