Freetype 2.9.1 renders fonts poorly on Windows 10

[paharvey]

Platform: Windows 10

Architecture: 64-bit

Freetype 2.7 contains a change that led to poorer quality font rendering on Windows.

• Your Java 8/9/10 builds for Windows appear to use Freetype 2.5.3, so fonts look fine.
• Your Java 11+ builds for Windows appear to use Freetype 2.9.1, so fonts look worse.

As a workaround, users can use pre-2.7 font rendering by setting an environment variable:
FREETYPE_PROPERTIES=truetype:interpreter-version=35

A better solution may be to revert back to an earlier version of Freetype for Java 11+. Even better, someone could work out how to set "truetype:interpreter-version=35" as the default when compiling Freetype as part of the OpenJDK build process.

Note that most OpenJDK distributions also appear to be impacted by this issue. There are a few bugs already posted on OpenJDK's bug tracking system, but I am unable to add comments to those bugs: https://bugs.openjdk.java.net/browse/JDK-8214538

[karianna]

Platform: Windows 10

Architecture: 64-bit

Freetype 2.7 contains a change that led to poorer quality font rendering on Windows.

• Your Java 8/9/10 builds for Windows appear to use Freetype 2.5.3, so fonts look fine.
• Your Java 11+ builds for Windows appear to use Freetype 2.9.1, so fonts look worse.

As a workaround, users can use pre-2.7 font rendering by setting an environment variable:
FREETYPE_PROPERTIES=truetype:interpreter-version=35

A better solution may be to revert back to an earlier version of Freetype for Java 11+. Even better, someone could work out how to set "truetype:interpreter-version=35" as the default when compiling Freetype as part of the OpenJDK build process.

FYI - I think this should be the actual fix

Note that most OpenJDK distributions also appear to be impacted by this issue. There are a few bugs already posted on OpenJDK's bug tracking system, but I am unable to add comments to those bugs: https://bugs.openjdk.java.net/browse/JDK-8214538

[ali-ince]

@paharvey can you please confirm that setting FREETYPE_PROPERTIES=truetype:interpreter-version=35 environment variable has any positive effect on your environment?

With the test I've done locally (i.e. running visualvm) it seems to have no effect. And furthermore, for this case reverting back to previous freetype versions / upgrading to the latest version does not change anything at all.

Will keep investigating.

[ali-ince]

Hmm, ok - my bad. The issues I was seeing were about HiDPI support.

[M-Davies]

Hi @paharvey . After discussions in Slack, we found that we are using Freetype 2.9.1 for JDK11+ builds since we do not set the freetype version in our windows setup script. The solution for this would be to simply add a line in the elif statement for JDK11+ builds that exports our freetype version into the build args.

Once I have confirmed that using 2.9.1 is not required for JDK11+ on both Hotspot and OpenJ9 on slack, I can make this change.

[karianna]

Freetype is now at 2.10.2 so I think we should upgrade to that (and see if it fixes the OP’s issue).

[karianna]

Looks like https://bugs.openjdk.java.net/browse/JDK-8217731 was backported. @paharvey are you able to try Adopt 11.0.7 build and see if the issue has been corrected?

[M-Davies]

I created a PR as we should upgrade freetype anyway if there is a newer version out. I'd like to sit on it for a little while though as I wait for the opinions of the openj9 folks

[sxa]

we should upgrade freetype anyway if there is a newer version out

Upgrading just because there's a later version is potentially risky though.

Have we verified whether the OP's issue is resolved by 2.10.2 yet? Otherwise this conversation is rather pointless and 2.5.3 would likely be the better option.

[M-Davies]

Have we verified whether the OP's issue is resolved by 2.10.2 yet?

I'm not sure how the OP tested that the fonts were not rendering properly. Without knowing that, I'm not sure how we can verify if the issue is resolved by using 2.10.2

[sxa]

The test case is in the openjdk bug referenced above. However I cannot reproduce the problem using the Windows x86-32 builds on my system (Which admittedly is an aarch64 one!) with either 11.0.7 or 11.0.5, but we should verify on a proper WIn/x64 system

[karianna]

@paharvey Can you test with the latest 11.0.15? This should be resolved.