FontEngine.LoadFontFace_With_Size_FromFont_Internal() takes a long time

Hi,

I am trying to draw lots of player usernames using TextMesh Pro, Unity 2019.1.3f1.

I can't know in advance what glyphs these usernames are going to contain. My main font is static, while all the other fallback fonts are dynamic.

There are potentially hundreds of these player usernames, but only a subset are visible at any time. I use an object pool to reuse these tmp texts.

I understand that this isn't the typical use case where players are inputting text one character at a time, but I do need to speed things up.

Would love to understand what FontEngine.LoadFontFace_With_Size_FromFont_Internal() is doing, and how I can potentially speed it up. Is it possible to move it to a background thread?

Thank you!

 

See the following post which details improvements that I have made in this regard.

 

Thanks for the reply.

I'm already on 2019.1. Does this mean I already have those improvements?

 

I have not submitted those changes yet but they will eventually show up in some version of 2019.1.

 

@Stephan_B Sorry to bother you, but are any updates on this?

How can I get notified when the changes have been patched in? Is there an expected date?

 

Once the new release is out, I'll update the title on the top sticky post to reflect version 1.4.2 and 2.0.2 is now available.

The PR for the changes to the FontEngine is in process so it might land in the next 7 - 10 days but not sure when the cut off is for the next release of 2018.4.x.

Although some of the changes are in the FontEngine, I did post a modification that can be done in the package that should help.

Let me know what kind of improvements this yields for you.

 

Good to know. Thanks!

 

@Stephan_B I don't mean to bother you, it's just that it's been two months and I'm wondering if there are any updates?

 

A big update is coming which will now be version 1.5.0 for Unity 2018.4 and 2.1.0 for Unity 2019.x.

In hindsight, I should have released what I had back then but as usual one thing led to another (ie. feature here, bug fix there, etc.) so it ended up delaying the whole release.

I'll provide an update over the weekend.

 

Thanks, looking forward to that update.

 

@Stephan_B Sorry, is the update up? Haven't seen it.

 

Not there yet still working on it.

 

@Stephan_B On this subject, is there any way to either A) have the fall-back font generate its glyphs in a thread, or B) perform some kind of pre-warming so that there isn't a multi-second freeze as is sometimes the case?

 

Please describe how you are using the dynamic system and fallbacks and encountering this freeze as the reported behavior related to the FontEngine.LoadFace in this thread was addressed.

The process is multi-threaded but most of the time since the dynamic system should mostly be used to handle user input we end up processing just one glyph at a time as user type them. Having said that, this process should not be noticeable to an end user even on slow mobile devices.

If you know that you are going to need to add a bunch of characters to a font asset at runtime, you can use the
FontAsset.TryAddCharacters() functions.

P.S. Be sure to test using the latest release of the TMP package which is version 1.5.0-preview.13 for Unity 2018.4, version 2.1.0-preview.13 for Unity 2019.x and version 3.0.0-preview.13 for Unity 2020.x.

 

Thanks, @Stephan_B. I'm currently on 2.0.1 with 2019.3.1f1. I'll try 2.1.0. Sorry if I misunderstood the context of the thread. The situation I'm running into is I have a leaderboard, and when Chinese characters get displayed for Chinese users' names, it uses Arial Unicode as the fallback font (set in the global TMPro settings), and there's about a solid 1 second or more freeze (Oculus Quest) where no frame renders, which of course for VR is devastating. If I remove the font from the fall-back (so that there are none set to fall-back to), then the characters render as blocks but there is not freeze.

 

How many names / characters (roughly) does the leaderboard contain?

How complex is your fallback structure? Ie. Do you have several local fallbacks + several global fallbacks or just a primary font asset with this Arial Unicode fallback?

What are the generation settings on this fallback? SDFAA with Default 90 with padding of 9?

 

@Stephan_B It is only about 4 or 5 Chinese characters, rendered using Arial Unicode.

There is only a single global fallback font: Arial Unicode.

The generation settings are:
Dynamic
SDF32
Sampling Point Size: 40
Padding: 5
Width/Height: 2048

Thanks so much for looking into this!

 

The SDF over sampled modes like SDF, SDF8, SDF16 and SDF32 are not suitable for dynamic SDF generation as they are way too slow.

You should be using SDFAA with dynamic font asset where the default sampling point size is 90 and padding is 9.

 

@Stephan_B thank you for the tips. I'll try that and see if that addresses the issue. Thanks!