Performace Problems

rincewind · Postby **rincewind** » Thu Sep 16, 2004 23:12

Hi,

I've created a GUI using the Taharez Look with several buttons. Renderer is Ogre.
When I move the mouse over the column of buttons, the fps slow down to a crawl of 20 (usually I get about 100), and as a result the mouse reacts really slow. This doesn't happen if I just move the mouse but stay inside a single button.

I already tried to cap the amount of injected mouse movements but the problem seems to be the switching to the hover-images and back.
I don't need the hover-images so I have them defined to the same ones as the normal images. Is there any way to disable the switch all together?

On the other hand it appears weird that the switch should cause that much of a performance hit since the images are in the same imageset, and so in the same texture...

Any ideas what I can do to improve the speed?

Thanks,

Rincewind

Postby **CrazyEddie** » Fri Sep 17, 2004 08:21

There's no option to disable the state switches for Taharez buttons, though as you said, this really shouldn't cause that much of a performance hit. I'll double-check over the weekend to make sure I'm not doing anything silly that's causing the performance drop.

Some other information might be useful: OS, Hardware/drivers, what else is in the scene, performance rates without any CGui at all, number of Gui elements visible, display resolution, etc, etc...

Is this a debug or release build? If it's debug, you can't put any stock in those figures at all; what happens in release mode?

CE.

rincewind · Postby **rincewind** » Fri Sep 17, 2004 09:13

Wow, this is probably the fastest help-forum I've ever seen!
Thanks for the fast reply.

Stupid me was of course in debug build, so right now, I'm compiling everything as release (takes a while for Ogre

).
For now, here's some more info: OS is Windows XP SP2 Pro running on an Athlon XP 2200+, Radeon 9800SE with Catalyst 4.8.
I tried both GL and DX9-mode for Ogre. Fullscreen or windowed didn't make any difference.
With GL, the normal speed when not doing anything to the GUI is about a 100 fps, with dx it's about 70 (might be they don't like small vertexbuffers...).
Once I start moving the mouse in an unoccupied area this drop to about 60, when creating a lot of onMouseOver-events for the buttons, it goes down to 20.
There's 14 buttons on the screen. I've also a smaller screen with only 4 buttons, and there, the slowdown is only down to about 70 fps in GL (so not really noticable).

Greetings and thanks again,

Rincewind

The amount of buttons

Postby **CrazyEddie** » Fri Sep 17, 2004 12:01

On that set up I'd expect no problems when running under release. The only time I have seen these huge slow-downs has been under the debug builds. I'm not doing anything extra in debug; I think it's a combination of many factors.

Once beta-1 is done, I will invest some time seeing where performance improvments can be made, although I believe that Ogre will always pay a tiny bit more in performance than the raw APIs, due to the extra layer.

CE.

rincewind · Postby **rincewind** » Fri Sep 17, 2004 15:07

Ok, got the Release Build running (always stupid if you forget to make all changes to the build-config to all targets right away, takes ages to figure out what changed).

So, now I get about 230 fps in when not doing a thing and it drops to about a 180 fps when moving over the buttons. So it works now.
Still don't know where the performance drop comes from.

but I guess it's not very high priority now.
Thanks again for the help.

Rincewind

Postby **CrazyEddie** » Fri Sep 17, 2004 18:34

I think the drop is basically coming from the full-redraw triggered when something changes (in this case the button to / from the 'hover' state). When nothing changes, there is much less work being done in order to draw the Gui (though the button should be one of the 'cheaper' widgets to redraw).

You may benefit from some changes I'm making for beta-1, which improves performance a bit for the quad queueing stage, although this code is not entirely finished yet and contains some breaking changes (mostly involving updated data files). Anyway, I'd certainly give it a go when it's released (hopefully) in two or three weeks and see if you notice the difference.

CE.

rincewind · Postby **rincewind** » Sun Sep 19, 2004 17:30

Just a thought about the full-redraw. How about testing the all windows with intersection with the button that changed state. You could then mask off everything else with the stencil-buffer and just redraw those.
I haven't looked too closely how CEGUI does it currently, so it might be a stupid idea...

Rincewind

Postby **CrazyEddie** » Mon Sep 20, 2004 08:35

At the renderer level there is no concept of a Window, just the images that are used to construct the windows, this needs to be considered when thinking about optimisations. It could be possible to do some optimisation at a higher place in the abstraction, though this would need to remain renderer implementation neutral.

There's probably a whole host of optimisations that could be done, though I will admit that I have not given such things a lot of consideration. Once the system is in a more 'complete' state, I'll certainly be looking more closely at what can be improved.

Thanks for the suggestion, I'll certainly see if this idea could be used once I get to a point where optimisation is being worked on (which will probably be post beta-2)

CE.

rincewind · Postby **rincewind** » Mon Sep 20, 2004 11:44

I don't think it's that high priority either. The thought just came up, but you are right, this is something to consider later once the desired features are all in there.

Again, this project is just great!!!

Rincewind

CEGUI (Crazy Eddie's GUI) Forums