Yeah. Faster.
-phil.
On 4/4/20, 9:57 PM, Sergey Bylokhov wrote:
Hi, Phil.
Does the SolidTextRenderer have some benefits over AATextRenderer so
we have to use it by default on 10.13 on jdk15?
On 4/4/20 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.
