[OSX] Replace FreeType by native glyph rasterization #8518
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
LordAro
reviewed
Jan 8, 2021
michicc
force-pushed
the
pr/osx_font
branch
2 times, most recently
from
b1a3e45
to
e14b38e
Compare
|
Finally got this tested again - the rendering looks higher quality than FreeType for sure. Particularly noticeable with bold fonts I've found (e.g., Tahoma Bold) - FreeType is very 'squashed together', with the native rendering looking considerably better. Certainly from a visual point of view (plus getting rid of a dependency in the Mac builds!) I'd be keen for this to go in. |
|
@orudge Got a personal taste question for you: If you enable font anti-aliasing (config option only I'm afraid), which rendering is better:
|
This looks just a touch clearer to me I would say; as you say, it is very subtle. |
On a display, especially with small fonts or low pixel sizes, sans-serif fonts are usually easier to read than serif fonts.
|
Artistic 2 choice applied. |
TrueBrain
approved these changes
Feb 14, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
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.
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.