[OpenJDK 2D-Dev] RFR: 8220150: macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs

[Kevin Rushforth]

+1

-- Kevin


On 4/4/2020 8:16 PM, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220150
> Webrev : http://cr.openjdk.java.net/~prr/8220150/
>
> We are being returned grey glyphs when asking for B&W.
> The same is true for LCD, although they are a little different and not 
> the main problem.
>
> The main problem is that when our software loops designed for B&W are 
> handed greyscale
> glyphs, every byte encoded pixel that has a bit that is 1 is treated 
> as 255.
> Once we are in those loops it is too late and the result is horrid 
> blocky text.
>
> This hasn't been affecting too many people since the OpenGL pipeline 
> treats
> the bytes as a mask so works for both B&W and greyscale.
>
> But if you are drawing to a BufferedImage  the problem is there.
> It can popup in a UI if the UI uses a s/w image as the backbuffer - in 
> fact
> that is how this bug was reported.
>
> There isn't anything I can find that will make 10.14 generate B&W 
> glyphs again -
> the workaround to change a system default is not viable for us, and it 
> is a lot
> of work to use freetype in this case and that will almost certainly 
> cause inconsistencies.
>
> There is no sure way to know that you are going to be handed AA 
> instead of B&W.
> So the essence of the fix is that on 10.14 and later we use the AA 
> rendering loops
> to draw B&W. They will properly blend even if somehow we were handled 
> B&W glyphs.
> This is the change in SurfaceData.java.
>
> The other changes are a small optimisation, so that if B&W glyphs are 
> requested we
> re-direct to greyscale. This prevents wastefully caching the AA glyphs 
> twice - once
> as AA and once as (supposedly) B&W.
>
> -phil.
>
>