JDK-8220150 : [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7u6,8,11,13,14,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-03-05
  • Updated: 2021-11-05
  • Resolved: 2020-04-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 15 JDK 8 Other
11.0.9-oracleFixed 15 b19Fixed 8u270Fixed openjdk8u322Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
Fonts are not clear after mac os mojave upgrade 
Comments
Fix request (8u) Backport is requested for parity with 8u-oracle. Review approval: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-October/014343.html
13-10-2021

Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.9-oracle. Applies clean.
22-06-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/a57d3822c2fa User: psadhukhan Date: 2020-04-11 05:04:11 +0000
11-04-2020

URL: https://hg.openjdk.java.net/jdk/client/rev/a57d3822c2fa User: prr Date: 2020-04-06 19:02:07 +0000
06-04-2020

Yes, I am going to add this to the exclude list along with some other test failures.
08-02-2020

Would it make sense to exclude this test on Mac for the time being? We're seeing it in our CI, as we have a new Mac system introduced.
06-02-2020

This causes sun/java2d/loops/RenderToCustomBufferTest.java to fail. See https://bugs.openjdk.java.net/browse/JDK-8234607
13-01-2020

This does need a fix
07-01-2020

The component that has the problem is displaying the text using B&W (aliased) font rendering. No one uses this any more. Swing L&Fs have since 2006 picked up the desktop settings for font smoothing. The best solution here is to find it and where the paint occurs (ie where you get the callback to paintComponent with the Graphics instance parameter), and set RenderingHint.VALUE_TEXT_ANTIALIAS_ON or RenderingHint.VALUE_TEXT_ANTIALIAS_LCD_HRGB. There are some more sophisticated ways to get the right setting as well See https://docs.oracle.com/javase/8/docs/api/java/awt/doc-files/DesktopProperties.html As to why this is a problem with macos 10.14, it appears that Apple have changed font rendering in that release. Previously when JDK asked for B&W glyphs, we got them. Now we get anti-aliased glyphs. Interestingly they are not identical to what we get when we explicitly request AA glyphs .. but pretty close. When this is run on an accelerated Swing backbuffer the OpenGL code treats the glyphs via the same path for aliased and anti-aliased where aliased pixels are 0 or 255 and anti-aliased are anywhere in that range. The application used here is OK in other places either because it is using a standard Swing L&F, or setting AA, or running on the Swing backbuffer. But in this one component that looks bad, it is drawn to a software Java 2D BufferedImage. This means all drawing also happens through platform independent C code where there are separate loops for aliased and anti-aliased. When the B&W loops get a pixel which has any non-zero value it is interpreted as meaning "ON". This is why we get thick blocky glyphs as those edge pixels were supposed to be only partially on. This is not a bug in that code. It should only be fed B&W glyphs. And macos should have returned those to JDK. Additionally I confirmed what others on the internet have complained about - macos no longer generates LCD glyphs. The lCD glyphs we request are returned as antialiased glyphs (same value for each component). I can also confirm that running this command : defaults write -g CGFontRenderingFontSmoothingDisabled -bool NO Fixes both these issues - thus proving the source of the problem) You can revert this with defaults delete -g CGFontRenderingFontSmoothingDisabled This probably needs a bug filed with Apple and the resolution of this may be some way off. It would be very unfortunate to have to make risky changes to the platform independent font code to handle this. But the best solution is to update affected apps to use AA text. And that defaults setting is a short term workaround.
12-12-2019