Is there a known performance issue with large font files?
In an effort to support my non-english users I tried using a custom font form the google noto set. UI Performance plummeted compared to other custom fonts I had be testing out. Then I noticed an average ttf font is around ~200KB and the NotoSansCJKjp-Medium.otf is about 16MB!
Is this to be expected or could there be som inefficiency in the way JUCE is accessing glyphs?
Yes, I’m in a release build and setting the typeface only once.
That is very interesting. Have you tried running it through a profiler, to see where the bottle-neck is?
No, I ran out of time to dig any deeper.
When I get back to it I’ll try other font formats plus some others of that size.
Just wondered if it was a known issue or something that had been encountered before
IIRC we’ve seen a weirdness with CoreText such that when loading a font from memory (i.e. not just loading a named system font), it could be really slow for some unknown reason. There was nothing we could do about that - it was just something strange going on inside the OS code, but it might explain what you’re seeing?
But yes, you’d really need to profile to see whether it’s a problem loading the font, or creating the glyphs, or rendering the glyphs, or something else entirely.
OK, so I finally got some time to investigate a little bit:
The bulk of the time is spent in CoreText creating the lines for the glyphs, using CTLineCreateWithAttributedString() called from juice::Font::getGlyphPositions().
I think the real culprit is OTL::GCommon::IterateLangSysTables() which might be getting called every time a glyph is generated, which is many many times for every paint call.
I guess that suggestion I have seen about ‘manually’ caching glyphs would be a good place to look next - and I wonder if glyph caching might be a useful thing for juice to be doing automatically.
