[CLOSED] Performance problem: Font loading & resizing

If you found a bug in our library or on our website, please report it in this section. In this forum you can also make concrete suggestions or feature requests.

Moderators: CEGUI MVP, CEGUI Team

User avatar
mmixLinus
Quite a regular
Quite a regular
Posts: 71
Joined: Fri May 20, 2011 08:46
Location: Lund, Sweden
Contact:

Re: [CLOSED] Performance problem: Font loading & resizing

Postby mmixLinus » Sun Jan 06, 2013 23:37

Hi,

I just remembered that there is a performance issue with stretching too, don't forget. :wink: My experience was that resizing a root window (with AutoScaled="true") spent twice the time compared to one font load. Stretching might be performing more or less the same stuff as loading. Perhaps. I don't know.

I'm not really in favour of splitting font files (ok, that was an understatement but I'm looking for less work, not more :D). Some languages are large anyway .. >10k glyphs.. so they will still want to load quite a lot.

Just me tuppence..
/mmixLinus
MMiX.Me 3D Music Player
Galaxy Navigator 3D - 2 million stars (ESA's Gaia satellite)
(YouTube|Facebook)

Montred
Not too shy to talk
Not too shy to talk
Posts: 42
Joined: Sat Nov 10, 2012 06:45

Re: [CLOSED] Performance problem: Font loading & resizing

Postby Montred » Mon Jan 07, 2013 03:23

Don't worry, this is the source of the scaling issue too. I tried it. :)

The reason that the time is double during stretching may be that cegui is being refreshed twice, perhaps you are doing an unnecessary redraw signal for good caution? I say because I've had similar problems in the past. In any case, now the font updating of a large font takes 20 ms instead of 2 seconds for me, so 40 ms isn't a big deal either. I suspect that's your problem because another 5 seconds for rendering the glyphs sounds like too much unless you have glyph of every different unicode block on screen.

------------------------------------------

EDIT: Moved the off-topic fallback suggestion to another thread

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

Re: [CLOSED] Performance problem: Font loading & resizing

Postby CrazyEddie » Tue Jan 15, 2013 10:51

I looked into what I thought would be the best way to do this mod this morning, and decided that I could implement it easier than I could try to explain it :lol: I've 99% finished that, and later will either commit it, or post a patch here for others to try out first - not decided yet.

CE.

Montred
Not too shy to talk
Not too shy to talk
Posts: 42
Joined: Sat Nov 10, 2012 06:45

Re: [CLOSED] Performance problem: Font loading & resizing

Postby Montred » Tue Jan 15, 2013 11:18

CrazyEddie wrote:I looked into what I thought would be the best way to do this mod this morning, and decided that I could implement it easier than I could try to explain it :lol: I've 99% finished that, and later will either commit it, or post a patch here for others to try out first - not decided yet.

CE.


Awesome, thanks! :)

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

Re: [CLOSED] Performance problem: Font loading & resizing

Postby CrazyEddie » Tue Jan 15, 2013 12:59

Hi,

I have committed this modification here: https://bitbucket.org/cegui/cegui/commi ... bad89262e6 That's the v0-7 branch, I will merge to other branches later on today.

This basically has FreeTypeFont load the glyph information at the last possible moment before it's needed for any given purpose. I did not measure the difference in performance at all, but hopefully it's acceptable to you guys (if not, I'm not sure we can realistically do better with the current font implementation - it should be noted that we intend to replace this entirely in CEGUI 2.0 - yes 2.0 not 1.0 :P).

CE.

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

Re: [CLOSED] Performance problem: Font loading & resizing

Postby CrazyEddie » Tue Jan 15, 2013 13:34

Some additional testing has shown some issues with this modification - so if you're experiencing those issues, you'll have to bear with me until they get fixed :oops:

Montred
Not too shy to talk
Not too shy to talk
Posts: 42
Joined: Sat Nov 10, 2012 06:45

Re: [CLOSED] Performance problem: Font loading & resizing

Postby Montred » Tue Jan 15, 2013 14:13

CrazyEddie wrote:Some additional testing has shown some issues with this modification - so if you're experiencing those issues, you'll have to bear with me until they get fixed :oops:


Ah. I just tested it and was gonna report that the delay was gone, though I didn't test rendering yet. No hurry :D

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

Re: [CLOSED] Performance problem: Font loading & resizing

Postby CrazyEddie » Tue Jan 15, 2013 14:38

Ok, this is now fixed (and merged to other branches also). The new version is closer to your suggestion above, so does slightly more than my previous attempt, but this has the distinction of actually working properly :lol: Hope it's still faster than before :)

Montred
Not too shy to talk
Not too shy to talk
Posts: 42
Joined: Sat Nov 10, 2012 06:45

Re: [CLOSED] Performance problem: Font loading & resizing

Postby Montred » Tue Jan 15, 2013 16:08

Will try, thanks!

Slightly off-topic, but may I ask what are the expected font changes in 2.0? I didn't find anything on the forum about it.

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

Re: [CLOSED] Performance problem: Font loading & resizing

Postby CrazyEddie » Fri Jan 18, 2013 09:38

2.0 is a way out and as such we have lots of things we wish to address and have general ideas about some of those things but nothing is totally concrete. It works more in a way that one of us will say that "I want to deal with XYZ in 2.0" and the other will say "Cool, man!" :D

CE

Montred
Not too shy to talk
Not too shy to talk
Posts: 42
Joined: Sat Nov 10, 2012 06:45

Re: [CLOSED] Performance problem: Font loading & resizing

Postby Montred » Fri Jan 18, 2013 16:28

Ok, just wondering if there was a general problem with fonts that needed addressing while I was at it :)

The only problem I see right now with the way fonts are handled is that in a multiplayer game somebody could craft a 256 characters chat message that would contain a glyph from every page. This could cause a 5 seconds delay or something like that (no idea, haven't measured it.)

Do you think a different system where glyphs are added on demand on an individual basis be feasible? You would still keep them in pages, but the latest texture of the pack would have to remain open for writing. Also a lookup would be necessary for retrieving every glyph. I wonder if this is overkill just to address that particular "exploit". On the other hand it would reduce memory usage, which is not important at all if it's CPU memory, tbh.

Still, if we were gonna do something like that, I think that at least the latin range of characters (first 256) should still work the way it works now, for performance reasons.

EDIT: Corrected my message to eliminate the suggestion that the crafted message could cause the user to exceed video memory in some cases, because now that I think about it, those pages are never uploaded to the GPU, right? That explains why unicode messages didn't cause extra batches for me, duh. I thought that those pages were used as textures :D

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

Re: [CLOSED] Performance problem: Font loading & resizing

Postby CrazyEddie » Sun Jan 20, 2013 09:14

Montred wrote:Ok, just wondering if there was a general problem with fonts that needed addressing while I was at it :)

The general problem is largely the issues already highlighted :)

Montred wrote:The only problem I see right now with the way fonts are handled is that in a multiplayer game somebody could craft a 256 characters chat message that would contain a glyph from every page. This could cause a 5 seconds delay or something like that (no idea, haven't measured it.)

Yes, this is actually quite feasible - like you, I'm not sure about 5 seconds, but the delay could certainly be significant.

Montred wrote:Do you think a different system where glyphs are added on demand on an individual basis be feasible?

Well, something like this is how it used to be and under that old approach you could also pre-declare individual glyphs and ranges of glyphs in the font file. These features were removed in the current contributed rewrite - I have no idea why and was absent when it happened. Not that I'm shirking responsibility for the current state of things - I've had many years since to correct it and have not done so.

Also, I will add that fonts do (or may) use video memory - the glyphs are eventually all rendered to textures, so if the textures containing those glyphs are in video memory, then exhausting video memory is theoretically possible.

CE.

Montred
Not too shy to talk
Not too shy to talk
Posts: 42
Joined: Sat Nov 10, 2012 06:45

Re: [CLOSED] Performance problem: Font loading & resizing

Postby Montred » Sun Jan 20, 2013 17:41

CrazyEddie wrote:Also, I will add that fonts do (or may) use video memory - the glyphs are eventually all rendered to textures, so if the textures containing those glyphs are in video memory, then exhausting video memory is theoretically possible.


But only those that are used in text right? What I'm concerned here is about an asymmetrical attack, where an user only has to send 256 chars over the network through chat and that results in 65536 glyphs being rendered and taking space (although the cpu ram space doesn't concern me much, if it was gpu, it would). An attacker sending a 65536 length message doesn't concern me much because the simple anti-spam measures of the game and the network latency would lessen the impact.

Just to be sure I'm understanding it right. The big atlases that contain 256 chars each always stay in cpu ram, right?

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

Re: [CLOSED] Performance problem: Font loading & resizing

Postby CrazyEddie » Tue Jan 22, 2013 09:31

The textures contain an unspecified number of glyphs - normally at least 256, but perhaps more - this is to avoid situations where you might end up with wasted space on a texture. Being textures, they will (most likely) get uploaded to video ram at some point so they can be used by the GPU for texturing.

We discussed this a little yesterday, and what you describe is a legitimate scenario for exploit. If not to exhaust video memory to a point of failure, then certainly to create an issue of much 'thrashing' as textures get swapped into video memory. There is no quick fix for this, Kulik would obviously consider such issues in his font system rewrite, but that is a way off. We are also somewhat restricted in what we can do in the stable branch of the code (that's not to say that attempts to address such issues are completely off limits, but rather would need to be done in an appropriate manner - which basically means maintaining API and data file compatibility).

To be honest, it's really surprising that nobody has ever questioned this potential for attack previously or that nobody has reported this as actually happening somewhere. So I thank you for raising this.

CE.

Montred
Not too shy to talk
Not too shy to talk
Posts: 42
Joined: Sat Nov 10, 2012 06:45

Re: [CLOSED] Performance problem: Font loading & resizing

Postby Montred » Wed Jan 23, 2013 01:03

Ah sorry, I misunderstood what Image::Draw does, it actually queues the region to be rendered and I thought there was some sort of blitting to a texture.

Ok so, can't we fix w/e problems we see with the font systems progressively and without breaking the API? I don't see why this would require a total rewrite.

We could have an array "unsigned short *d_glyphTable" in every Font for example. Its size would be d_maxCodepoint. So in the case of a huge unicode font with 64K characters, you are using 128K of ram which I think it's acceptable if you are using huge fonts. It would hold indices to the position of glyphs in the pages. So if the number is 258 you know it's on the second page, 3rd position. For the first 256 characters (latin range) they could be always rendered and the lookup could be skipped. I know you just said sometimes they hold more than 256, but is that worth it? This would require the last page of the lot to remain open for writing (dunno if that means an overhead.)

This would prevent the asymmetrical attack, although it leaves room for some annoyances, though they would require a lot of text to be sent. Do you see any other problems with the current font system that this wouldn't address? I could do this, now that I have hg setup it's a piece of cake.


Return to “Bug Reports, Suggestions, Feature Requests”

Who is online

Users browsing this forum: No registered users and 12 guests