JDK-8234607 : [macos] RenderToCustomBufferTest fails on macOS 10.14
  • Type: Bug
  • Component: client-libs
  • Affected Version: 8,11,13,14
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2019-11-21
  • Updated: 2020-01-13
  • Resolved: 2020-01-13
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.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8220150 - [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs
Relates :  
JDK-8220150 - [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs
Description
This test rarely fails on macOS in mach5.

Update:
Looks like the test is "stable", it is always passed on macOS 10.13.x and always failed on macOS 10.14/10.15.

It looks like this is not a test bug, the actual rendering of font is different on macOS 10.14+,
but the test does not use platform-specific API or any acceleration, the general shared
loops are used only. 

probably related to JDK-8220150
Comments
The test renders to an RGB buffered image and a custom one. I've confirmed that the custom case in the test goes through the Java level loops and that those - even for aliased text - use a MaskFill operation. See /src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphList.java The test then compares the rendering of that with the native loops which assume bi-level. Consequently they are different and the test reports a failure. So definitely a dup of JDK-8220150
13-01-2020
Does it affect 13?
22-11-2019