CEGUI (Crazy Eddie's GUI) Forums

Hi

I am using CEGUI with Ogre, and I need to display 9 text boxes and 2 spinners.

I need to update them as frequently as I can, but for now I am only doing it every 1/2 second, and updating only 3 text boxes at the time. Even so, it drops my frame rate, from ~1000fs, to ~100fps.

So what do you recommend is the fastest way to draw and update text?

Thanks

Are your measurings done in debug mode or in release mode ?
One issue I know is that text rendering is very slow in debug mode!

(displaying a text of approx. the screen size drops my framerate to 2-5 fps in debug mode)

Release mode should be somewhat better. Also you may search the forum, sometime ago, I think somebody tried to solve this issue by rendering the text onto one quad, instead of rendering one quad per char. But I don't remember exactly

Hope that what I said is not totally useless

Hi,

I obviously second the idea that you can not take anything meaningful away from performance testing debug builds. Debug builds are slow.

Also to consider is what else is in your scene. A drop from 1000 to 100 FPS with nothing else being rendered is not indicative of any real performance issue, and as such does not mean that adding twice as many text boxes would drop you to 10 FPS.

Did you already try rendering all the boxes as you need? What were those results like?

Also of importance is the general arrangement of the imagery for the rest of the widget; although rendering frequently changing text can be expensive, the situation is not as clear cut as that if your widget imagery consists of a lot of sub-images, since they can then become more expensive than the text to render.

I guess the top piece of advice would be to not write back the same string value to a window - it causes an unnecessary redraw and costs you time.

CE.

If you are running at 1000fps what exactly are you rendering to acheive that? A black screen? A couple textured quads? You cannot compare rendering nothing to rendering something and expect the results to /not/ be dramatic - rendering is what takes the majority of processing time.

Unless you are rendering thousands of characters, I doubt you have much of an actual problem. I use CEGUI in a full blown flight-simulator that has to render photo-realistic terrain, thousands of trees, buildings, and various misc objects, as well as processing a fairly realistic flight model that sustains over 110 fps on an average system.

Now, regarding "frequent updates" I can confirm there does seem to be an issue here when running in Debug mode. Just as a very simple example, if you are in an editbox and hold down a character the framerate just plummets; once you let go, it returns to a normal rate. I'm not sure why this occures, perhaps there is a real issue here when running in Debug? But when running in Release this doesn't appear to be happening.

Ok, fair enough, I didn't post any pictures

Not updating CEGUI


Updating CEGUI



I am building in release, and unfortunately, I have to update my info quite frequently, as when the simulation runs, I would like to see the values changing.

So any ideas on how to improve the performance?

Thanks

You might add a little interval between your updates, since updating textfields each frame is (very) expensive. So you only actually update the values when more then 1/10 of a second has passed or so.

Also, only update the fields when the new value differs from the current. Just wrap the updates within an if-statement which tests for non-equalness.

HTH.

While I second the advice given by scriptkid, that's certainly a dramatic drop in FPS, and to be honest a little more extreme than I might have expected. Wow!

CE.

Ok,

I have found part of the solution + the reason.

My root DefaultWindow in the layout, covers the entire screen. On top of it there is a text with "simulation paused" and the FrameWindow on the left. So most of the root window is transparent, but it is there.

I reduced root to cover only the panel on the left, after that, it doesn't drop many fps anymore. Still about ~15%, but that's not a problem.

So the solutions is, to cover only what you need, and no more of the screen.

I think the problem began because I used the CEGUI Editor to create my GUI, and by deafult it creates a root object that covers the entire screen.

Anyways, thanks.

Hi,

Thanks for posting this information and I'm happy you have a more acceptable performance. It's still an odd cause IMO and - time permitting - I intend to investigate this a little myself due to the original performance drop being so large.

CE.

Hi,

Can it be that your root window had a "one-transparent-pixel" image set as its background and it was TILED (repeated) all over the screen ?? that would cause A LOT of transparent quads to be drawn. change the proprety to STRETCHED and it should be MUCH faster!

I had that problem with just the border of a frameWindow and it was already a dramatic framerate increase for big windows, so the background should be even more.

Actually, using the STRETCHED proprety, I also have a transparent backgrounded window all over the screen and that works pretty nice. Or did I missunderstand something?

Hi,

Well I'm back with the same problem, because I need to actually use the whole screen, so:

Messing around I discovered that setting this two values to true in all my widgets, it speeds up.




So are there any other tricks like these to make it faster?

About the strech/tile, I'm not settings anywhere any of those two parameters. Where can that be set?

Hi,

ricardo_arango wrote:Messing around I discovered that setting this two values to true in all my widgets, it speeds up.

Code: Select all

Name="BackgroundEnabled" Value="True"
Name="FrameEnabled" Value="True"

That's really odd on two counts; first because not all widgets support those properties and second because setting them to true would cause more things to be rendered and so logically you'd expect it to be slower. Truly bizarre!

About the strech/tile, I'm not settings anywhere any of those two parameters. Where can that be set?

These are in the looknfeel. If you're using the unmodified WindowsLook, you'll probably not need to worry about this.

Would it be possible to post the layout xml and any other window creation/set up code?

CE.