Hi again!
I had this freaky idea earlier today where I decided to render my entire GUI to a texture and render this texture to the screen. This way, I don't have to go through my entire GUI rendering process every frame, which seems to double my framerate in GUI intensive situations. I only update this texture when when the GUI needs updating.
I can't shake off this dodgy feeling that this can't be a good way to do things though. Is there something I'm not aware of that could cause problems with this method, except the slightly increased memory usage and the fact that I have to manually go through the code and identify situations where the GUI will have to be redrawn
Are there any drawbacks to this?
Ronen Tidhar
No, there is nothing that will cause problems - your method will work as expected in terms of the what will get rendered. There is another issue however: this approach should be a LOT slower (at least twice), because of the greater rendered surface - the GUI surface when rendering into the texture, plus the entire screen surface when overlaying the texture. The most likely reason I can think of for your increased FPS is the reduction in the number of VB locks used when rendering the GUI - because now you only render the controls when their appearance change instead of every frame.
So, the better approach might be to investigate how you Lock() the VB's when rendering the controls - it should be done such that you don't serialize the CPU and the GPU by Lock()'ing VB's that are in use in the current or previous 2 frames.
Ubersnug
I think, it's a question, whether you really need to double framerate of your GUI I'm working on project, we have our own made GUI and it's framerate is quite high (about 1000 FPS on my NV6600 GT). So I would ask myself, whether such optimization is worth of doing.
huanghk
The cost of rendering your GUI may come from a number of things such as the size of textures you are using or the render states you are setting. It will help if you give us a little more information on how exactly you are rendering your GUI.
As far as rendering goes, are you using 1 texture and just extracting the needed parts of your GUI for each control from it
As far as updating your GUI, you could poll your widgets (buttons, and other controls) every 0.5 seconds or so and still get a reasonably interactive/reactive interface.
PS: The sample framework has a pretty decent GUI setup going. You should definitely take a look at it. The GUI component is located in the DXUTgui.cpp for native code and dxmutgui.cs for managed code.
I hope this helps.
BobF
If you have any significant amount of text in that UI, it can be a pretty good win. Certainly some UIs in published games slow down fps considerably. But that's more a problem of MMOs (which have a lot of complex UI and text) and an PFS game probably won't benefit from this method.
ricky3793
Well, thanks for your reply, but it doesn't really help all that much. You see, I'm actually done creating the GUI, and I know about the ways in which I can optimize it. For the moment, I don't need help there.
The point is that when I render the GUI to a texture when needed, then keep and render that texture to the screen, I seem to double my framerate. My question is simply whether there could be problems with this approach that I'm not seeing.
Diamant
Seems like a pretty straightforward more memory vs more speed trade off like any caching algorithm.
But other than the extra memory the only thing I can thing of is bandwidth issues and possible graphics card memory. I assume the worst case scenario is a full screen texture for your GUI which is a decent sized texture to send down to the card every time So if your game happens to be GPU memory limited or bandwidth limited then you may lose yor slow down. (though this assumes that the full screen quad is a lot bigger than the small bits of texture that you would probably use if you redraw the GUI each time. But don't forget to include the font textures in that calculation - if you use multiple fonts the sum of all those textures may actually get bigger than the full screen so you might actually be ahead of the game there too).