fastest way to draw and update text

For help with general CEGUI usage:
- Questions about the usage of CEGUI and its features, if not explained in the documentation.
- Problems with the CMAKE configuration or problems occuring during the build process/compilation.
- Errors or unexpected behaviour.

Moderators: CEGUI MVP, CEGUI Team

ricardo_arango
Just popping in
Just popping in
Posts: 6
Joined: Sun Jul 01, 2007 19:26

fastest way to draw and update text

Postby ricardo_arango » Tue Nov 04, 2008 18:29

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

Pompei2
Home away from home
Home away from home
Posts: 489
Joined: Tue May 23, 2006 16:31

Postby Pompei2 » Wed Nov 05, 2008 13:42

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 :)

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Wed Nov 05, 2008 14:39

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.

Jamarr
CEGUI MVP
CEGUI MVP
Posts: 812
Joined: Tue Jun 03, 2008 23:59
Location: USA

Postby Jamarr » Wed Nov 05, 2008 15:03

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.

ricardo_arango
Just popping in
Just popping in
Posts: 6
Joined: Sun Jul 01, 2007 19:26

Postby ricardo_arango » Wed Nov 05, 2008 16:48

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

Not updating CEGUI
Image

Updating CEGUI
Image


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

User avatar
scriptkid
Home away from home
Home away from home
Posts: 1178
Joined: Wed Jan 12, 2005 12:06
Location: The Hague, The Netherlands
Contact:

Postby scriptkid » Thu Nov 06, 2008 14:01

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.
Check out my released snake game using Cegui!

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Thu Nov 06, 2008 20:15

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.

ricardo_arango
Just popping in
Just popping in
Posts: 6
Joined: Sun Jul 01, 2007 19:26

Postby ricardo_arango » Thu Nov 06, 2008 23:07

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.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Fri Nov 07, 2008 09:44

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.

Pompei2
Home away from home
Home away from home
Posts: 489
Joined: Tue May 23, 2006 16:31

Postby Pompei2 » Mon Nov 10, 2008 09:23

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?

ricardo_arango
Just popping in
Just popping in
Posts: 6
Joined: Sun Jul 01, 2007 19:26

Postby ricardo_arango » Thu Nov 13, 2008 22:09

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.

Code: Select all

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



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?

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Fri Nov 14, 2008 07:11

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.


Return to “Help”

Who is online

Users browsing this forum: No registered users and 8 guests