Strange Performace Issues with Menus
I'm using the latest v9.02 in a scene editor I'm building for my project.
In the editor I have a single sheet that stretches the entire screen and then a tool bar that stretches across the top of the screen. The tool bar has three menus in it. The scene itself contains a terrain with some water and trees.
When I run the editor in Release mode, it sits at about 400 fps, which is pretty good. However, as soon as I put my mouse over one of the menus in the tool bar (i.e over the button for the menu that sits on the tool bar) the frame rate suddenly jumps up to over 800 fps. From then on, the editor runs at over 800 fps, never dropping back to 400 fps. It appears as though QuickGUI or the menus is doing a lot of processing or rendering or something when it first starts. Then when you put your mouse over the menu it resets itself or something like that and begins behaving normally.
What is also odd, is that in Debug mode it works in reverse. When I start the editor it runs at about 150 fps until I put my mouse over one of the menus, then it drops to about 100 fps and stays there forever.
Note that I'm not clicking on anything (i.e. I'm not activating the menu, giving it focus or opening it), I'm simply just moving my mouse over it for a second and then moving the mouse back over the scene.
Interesting observations. I don't really think there is any further optimizations I can do on QuickGUI's end, basically each Window is a texture, and whenever a widget's appearance changes, the entire Window texture needs to be recreated and drawn to screen. (Texture Caching) Each window adds an extra batch to the renderer, but this is very minimal, considering complex GUIs can result in only a few extra batches. With texture caching, the main resources are used when creating the texture, since each widget draws itself into its Window's texture in a recursive fashion. I've done performance comparisons against the fresnel demo in teh past, and the results were satisfactory to me.
Sorry I can't help any more in regards to performance. This is the 3rd main rewrite of the QuickGUI render system, and as far as I know there isn't much that can be done to make it more efficient, given the supported features.
Sorry, I wasn't implying that QuickGUI performs poorly. In fact, I think it is fantastic. I'm just wondering if you had any idea why the performance would improve significantly (more than double) when moving the mouse over a menu for the first time.
I know that updating a sheet that is 1600 x 1200 might take a bit of cpu to recreate the texture, but why this only occurs on the first time the sheet needs to be redrawn I don't really know. Actually, I wonder if the widget look up process is affecting things. Whenever the mouse is moved, I first find the window the mouse is over, and then ask the window what widget is underneath the cursor. The more widgets there are the longer it will take. Moving the mouse around in a menu window should be more efficient than moving it around in a sheet with lots of widgets. Not sure how substantial the perf hit is, basically I just test the position againt widget rects and widget visibility, shouldn't be that much of a hit I think.
I'm actually thinking it is something to do with the video card drivers or something like that, instead of QuickGUI. I notice that my video card seems to "spin up" (you know you get that really faint high pitch sound from it) as soon as I touch the menu. It's almost like the video card suddenly realises that it should be doing some work and gets off its lazy ass.
I just tried out RBGui. I built the exact same GUI in my editor using RBGui and I see the same problem. The frame rate more than doubles when I pass my mouse over a menu for the first time. Correct me if I'm wrong, but I believe you based some of your work off RBGui, so I was thinking that perhaps the issue existed in RBGui and now it has been inadvertently carried across to QuickGUI.
Oh and just for performance comparison (both have a toolbar along the top, with three menus and then a single window on the right of the screen):
QuickGUI - starts at 400 fps, then jumps up to 830 fps.
RBGui - starts at 400 fps, then jumps up to 940 fps.
So in this scenario, RBGui has a ~13% performance advantage.
Yah, I used RBGUI as a reference for QuickGUI's rendering system. If I remember correctly, RBGUI doesn't have a notion of a 'Sheet', so your ToolBar must be its own window. Since the window is smaller, updating the ToolBar texture will be faster.
Whats the specs on your dev machine?
Windows Vista Ultimate SP1 32 bit
Intel Core2 6600
4 GB RAM
ATI HD4850 512MB
Even if the ToolBar in RBGui is its own window, both RBGui and QuickGUI only add exactly one additional batch for my entire GUI. This indicates that RBGui must be using a full screen texture matching the underlying invisible window which covers the entire screen. Therefore I would imagine that at the same resolution, both RBGui and QuickGUI would need to render exactly the same number of pixels. Not sure... just a thought, haven't looked enough under the bonnet to really know what I'm talking about.
RBGUI doesn't use a full screen texture, everything is a window. For example, if you want to place a button on the screen with RBGUI, you will have to create a transparent window with a button. I've looked as well as asked, so I'm fairly certain on this. I was also speaking in regards to the amount of processing it takes to update a texture. If you hover over a menu item, the texture needs to be redrawn. When I say redrawn, I mean the texture itself needs to be rebuilt. All widgets within the window call their draw methods and draw to a texture, and after completion, the texture is drawn onto the viewport. Its easier to update the RBGUI stand alone toolbar that is maybe 800 x 15 pixels, vs the QuickGUI toolbar that is on a Sheet, that is 800 x 600 pixels. The main difference here is that QuickGUI has a Window meant to occupy the space of the viewport, provided by default as a convenience. You could always create a window with just a ToolBar on it and imitate the RBGUI style. With Sheets, its much easier to add buttons and other widgets directly to the screen, without needing to create a transparent window for each on-screen widget. Obviously, RBGUI is meant for widgets inside Windows, instead of overlay-style widgets.
Off topic: I'm almost done with the user defined event handler functionality. I'll probably update the 9.02 drop soon.
Ah, OK... cleary I have no idea what I'm talking about
haha, sorry if I sounded negative, thats not the case, I was just trying to outline how the systems work from what I know.
Its also possible there could be some perf hit due to skinning. I have no idea how skinning works in RBGUI, I just remember that when I first looked into it, it didn't seem flexible, and the script syntax wasn't as organized as I would have liked. Maybe it loads individual widget textures really quickly. I hope QuickGUI's current performance is acceptable to you and most people. If not, I suppose I could look into it, but it would probably require a lot of effort, since there aren't any obvious improvements to be made.
No, the performance is fine once I get past the menu glitch. I'm thinking of making the mouse start over the menu, which forces a mouse move event over the menu causing the performance to jump up to where it should be.
I'm still working with RBGui at the moment, mainly because I have all my GUI set up in it. I've even made some modifications to it specifically for my editor. However every time you put up a new version of QuickGUI I come and check it out. One day I hope to use QuickGUI, but at this stage RBGui is serving all my purposes and I personally really like the way it works. It just feels right. Perhaps I'm just used to it.
No offense intended, but QuickGUI just doesn't "feel" right yet. I spent most of my weekend building a GUI with it and kept getting frustrated trying to do things that were simple in RBGui. In addition, QuickGUI just doesn't seem to have the same level of polish and stability yet. I'm fully aware that QuickGUI is a work in progress... so I'm not meaning this as a negative thing. Just my reasoning why I'm using RBGui for now. I will continue to check out new versions that you put out and hopefully can continue to offer feedback to help improve it.
No offense taken.
I appreciate the feedback you've given, its very helpful in the development of the library. The library is very much a work in progress. Part of the problem with the library is that I spend so much time developing it, and I haven't yet gotten around to using all the features in my own projects.
I encourage you to give it another shot, after I've released the next version with the changes you asked for. Either way, thanks again!