Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OSX] Replace FreeType by native glyph rasterization #8518

Open
wants to merge 4 commits into
base: master
from

Conversation

@michicc
Copy link
Member

@michicc michicc commented Jan 7, 2021

Motivation / Problem

On OSX, text layout for TrueType fonts and more complex languages is done by CoreText. Font rendering on the other hand is done by the FreeType library, which assumes these two components never disagree.

Font selection in CoreText has lots of fallbacks built-in; it is extremly hard to not get some font glyphs from CoreText. FreeType on the other hand needs a reference to an on-disk font file. We try hard to match the proper font, but might not always succeed if CoreText is applying some magic for exotic scripts. It is unlikely to ever be a problem for any kind of western script, though.

Description

Letting CoreText render the font glyphs as well avoids any potential conflict or disagreement. It also removes an external dependency.

On average, CoreText appears to rasterize glyphs at least as fast as FreeType, often even faster. The implementation is similar to the Win32 implementation, as many concepts are analogue.

Limitations

CoreText and FreeType make slightly different stylistic choices rasterizing glyphs. This is most apparent when anti-aliasing is activated, as CoreText has a tendency to render "thicker". CoreText appears to render best when using native (HiDPI) resolution (separate PR incoming).

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')
    This is just a code move/rename, not a functionality change.
@michicc michicc added the OS: MacOS label Jan 7, 2021
@@ -1056,9 +1056,300 @@ static void LoadWin32Font(FontSize fs)
new Win32FontCache(fs, logfont, settings->size);
}

#elif defined(WITH_COCOA)

This comment has been minimized.

@LordAro

LordAro Jan 8, 2021
Member

Think this file needs splitting into per-os variants. It's getting a bit silly

This comment has been minimized.

@michicc

michicc Jan 8, 2021
Author Member

Yes, except of course that e.g. FreeType is actually not a real OS-variant. Both OSX and Win will still use FreeType if built with it.

If you have a good idea how to organise the split (probably including fontdetection.cpp), I'm willing to do it.

This comment has been minimized.

@orudge

orudge Jan 13, 2021
Contributor

I suppose it would be per rendering engine, rather than per-OS, a bit like we have SDL, Windows, Mac video drivers.

I would be quite keen to get native font rendering in on Mac if we can, to avoid the freetype dependency. That said, I haven't yet tested this PR, but hope to do so when I get a chance.

@LordAro LordAro requested a review from andythenorth Jan 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.