Slow TextLayout on OSX with memory-based fonts


#21

Thanks! This is essentially what we’re doing as a workaround too.


#22

Oh, that’s bad news. I haven’t seen any problem since the last fix was applied by Jules.

That path rendering workaround will make the font look different (thinner) and have no subpixel antialiasing on OSX with the native renderer. IMHO it would be better to have the option to fall back to the slower code by a preprocessor directive or even as a property of the textlayout… or even better would be a fix that works in all cases.


#23

Hi @jules
I am still seeing garbled text using the new method of checking the return value of CTFontManagerRegisterGraphicsFont.

I am testing with 10.10 and a 10.9 virtual machine and it appears that when I use a custom font (ProximaNova) the result of CTFontManagerRegisterGraphicsFont is true however the text displays like this: -

image

On my 10.13 machine it returns true and renders correctly, it seems like the result of CTFontManagerRegisterGraphicsFont might not be reliable for all fonts on all macOS versions. Do you think we might need to re-introduce some of the os version checks or is there another way?


#24

The below change seems to fix it for me by forcing older os’s to use the slow route. However I think SDK version might be muddying the issue too. We are using ‘latest SDK’ which in my case is 10.13 and when run on 10.9 and 10.10 the text renders slower but correctly, when run on 10.12 and 10.13 it renders really quick and looks fine.

#if JUCE_MAC        
if (SystemStats::getOperatingSystemType() >= SystemStats::OperatingSystemType::MacOSX_10_11)
{
    #if JUCE_MAC && defined (MAC_OS_X_VERSION_10_8) && MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_8
    canBeUsedForLayout = CTFontManagerRegisterGraphicsFont (fontRef, nullptr);
    #endif
}
#endif

#25

Any official word on this from JUCE? Should we avoid TextLayout altogether with memory fonts at the moment?


#26