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
fastest way to draw and update text
Moderators: CEGUI MVP, CEGUI Team
-
- Just popping in
- Posts: 6
- Joined: Sun Jul 01, 2007 19:26
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
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
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
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.
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.
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.
-
- Just popping in
- Posts: 6
- Joined: Sun Jul 01, 2007 19:26
- scriptkid
- Home away from home
- Posts: 1178
- Joined: Wed Jan 12, 2005 12:06
- Location: The Hague, The Netherlands
- Contact:
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.
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!
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
-
- Just popping in
- Posts: 6
- Joined: Sun Jul 01, 2007 19:26
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.
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.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
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?
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?
-
- Just popping in
- Posts: 6
- Joined: Sun Jul 01, 2007 19:26
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?
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?
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Hi,
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!
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.
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.
Who is online
Users browsing this forum: No registered users and 11 guests