+1
On 4/4/20 10:59 pm, Philip Race wrote:
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.
--
Best regards, Sergey.
