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

[Philip Race]

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.