[CLOSED] Performance problem: Font loading & resizing

[mmixLinus]

Hi,

I just remembered that there is a performance issue with stretching too, don't forget. 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 ). Some languages are large anyway .. >10k glyphs.. so they will still want to load quite a lot.

Just me tuppence..
/mmixLinus

[Montred]

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

[CrazyEddie]

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 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]

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 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!

[CrazyEddie]

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

CE.

[CrazyEddie]

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

[Montred]

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

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

[CrazyEddie]

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 Hope it's still faster than before

[Montred]

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.

[CrazyEddie]

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!"

CE

[Montred]

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

[CrazyEddie]

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

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.

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]

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?

[CrazyEddie]

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]

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.