Slow TextLayout on OSX with memory-based fonts



I noticed TextLayouts using memory-based fonts were rendering very slowly on OSX compared to Windows and ultimately tracked it down to a line which stops CoreText being used to render the Layout in TextLayout::createNativeLayout() (in This behaviour was added a few years ago with an explanatory comment stating there is a bug in CoreText which prevents the layout working with memory-based fonts. However, if I change the code such that CoreText is used to perform the layout I see a dramatic increase in speed and no apparent bugs. I have tested with a few versions of OSX (10.10, 10.11, 10.12, 10.13) and it appears 10.11 and later show no issues, those before that show garbled text.

The code below is what I am thinking of using as a “fix”, does this look appropriate?

bool TextLayout::createNativeLayout (const AttributedString& text)
     #if JUCE_MAC
      if (SystemStats::getOperatingSystemType() >= SystemStats::OperatingSystemType::MacOSX_10_11)
          CoreTextTypeLayout::createLayout (*this, text);
          return true;
     // Seems to be an unfathomable bug in CoreText which prevents the layout working with
     // typefaces that were loaded from memory, so have to fallback if we hit any of those..
     if (canAllTypefacesBeUsedInLayout (text))
         CoreTextTypeLayout::createLayout (*this, text);
         return true;
    ignoreUnused (text);
    return false;




Just tried this on 10.12 with some fairly text heavy sections of my application and the time spent rendering reduced significantly
It’d be cool to get the opinion of the JUCE guys to see whether this could be added

Thanks for the tip


Yep, thanks for the heads-up, George, I’ll take a look asap!


I saw the fix in the commit 2e0f6b5, but does that mean that memory-based fonts will now render incorrectly below 10.11? george-spitfire stated that OSX versions 10.10 and earlier show garbled text for memory-based fonts. Doesn’t that mean all that removed code would still be needed to support 10.7-10.10.


No, I didn’t remove any code relating to this. I did take the opportunity to rip out a pile of old legacy stuff for 10.5. But the fallback for pre-10.11 memory fonts is still there and older systems should still use it.


Hmm unfortunately the fix destroys my tooltips which are using TextLayout and fonts stored in memory. This is using the OSX 10.11 SDK with 10.11 deployment target on a 10.11 machine.
Before the commit:

After the commit:

I have my font in BinaryData and use LookAndFeel::getTypefaceForFont(…) to override the default fonts. Obviously it is using characters from the font, but the wrong ones.

Everything else in my GUIs seems unaffected, but as far as I know the tooltip window is the only spot a textlayout is used.

Edit:: weirdly enough it looks like all the char codes are just offset by 2 for rendering.


Setting canAllTypefacesBeUsedInLayout (…) to return false fixes my issue, but I can’t do that without patching JUCE.
My font does work correctly on OSX outside Juce and the same code/font does work on windows.
My conclusion is that at least with my configuration the old workaround is still needed even on pure 10.11 and I would very much like to have a way to override the new behaviour with the old one as I have no issues with speed.

Update: I tried running the same thing on 10.13 and there it is displaying correctly. I have no access to 10.12. Anything below 10.11 will use the old workaround and probably work in my case.

Bug with Alert Window text and embedded fonts in 5.3.1

Anyone else seeing this issue? Maybe it’s just my font that’s somehow weird.

I really wonder what that bug looked like that caused the workaround to be added… was it similar to what I’m seeing?