Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
I am still unable to get subpixel antialiasing to work for netbeans
with this patch. Are there circumstances (eg. certain surface
configuration or double buffering), where subpixel antialising will be
disabled?
On 27 May 2015 at 15:21, Torgeir Veimo torgeir.ve...@gmail.com wrote:
This looks extremely promising;
https://bugzilla-attachments-216655.netbeans.org/bugzilla/attachment.cgi?id=153888
I'd say don't let perfect be the enemy of the good, please get this
out into a jdk9 release and let the community provide more feedback.
On 22 May 2015 at 00:23, Andrew Brygin andrew.bry...@oracle.com wrote:
Hello Phil,
I have changed the default reverse gamma to 180:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/
I also did some experiments with the lcd contrast, and found that
value 160 decreases the discrepancy a bit: 21 instead of 29 with
the default lcd contrast value (140).
However, there still is the discrepancy, and at the moment I do not
see how we can avoid it completely with our rendering model.
It looks like that there is something more sophisticated than
just gamma correction, and we are unable to derive 'color independent'
glyphs from black-on-white glyphs provided by the native system.
I have also played with changing display profiles but it seems to
have no detectable effect.
Thanks,
Andrew
On 5/18/2015 11:19 PM, Phil Race wrote:
Hi,
So 1.79 is essentially 1.8 which is what Mac historically used as gamma.
So I'd pick 180 instead of 179
Since that value minimises the discrepancy it's looking positive but
there's still a discrepancy.
Before we 'live with it', I'd be interested to know what happens if you
set your display's profile to a generic RGB one.
How do the glyph shapes (if you try your best to ignore the colour) match
what other apps produce ?
-phil.
On 04/30/2015 06:21 AM, Andrew Brygin wrote:
Hello Phil,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
The main difference is in glyph generation. I have implemented 'reverse
gamma correction'
approach instead of 'glyph blending'. By default we use gamma value
which provides minimum
of discrepancy with gyph images produced by Apple's jdk. However, it can
be adjusted via
environment variable J2D_LCD_REVERSE_GAMMA (CGGlyphImages.m, lines 198 -
220).
Following chart illustrates dependency between the 'reverse gamma' and a
difference
in pixel values comparing to jdk6 from Apple:
http://cr.openjdk.java.net/~bae/8023794/best_reverse_gamma.png
Following set of images has been used for the comparison:
http://cr.openjdk.java.net/~bae/8023794/images/
An index of image corresponds to the value of reverse gamma used for
image
generation.
Beside this, following minor changes were done:
* RenderingHints.KEY_ANTIALIASING was removed form fontHints,
because it has no direct relation to text rendering, and does not
have
any effect at the moment.
* A comment regarding unevaluated rendering hints was added.
Please take a look.
Thanks,
Andrew
On 4/24/2015 7:33 PM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 4/23/2015 11:15 PM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
Why do we need this ? Historically in the (non-OSX) code this would
slow things down by making
text rendering go via ductus rendering.
If this really is a 'fontsHint' map, it seems it should not be here.
I agree that this particular hint has no direct relation to the font
hints,
and probably should not be here. I guess that KEY_ANTALIASING was put
here in order to force text antialiasing on when default text
antailiasing is evaluating:
http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
I do not think that it has any effect now, because we set text
antialiasing hint explicitly.
I will check whether it can be safely removed.
410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE
I thought you were removing this condition ?
I have rolled this change back, because at the moment lcd shader
produces ugly results in the case of translucent destination.
There is a separate bug regarding the translucent destination support:
https://bugs.openjdk.java.net/browse/JDK-8078516
I am going to relax this condition when(if) our lcd shader will be
ready.
In fact, this problem is not limited by ogl, because d3d and software
loops
has the same limitation.
CGGlyphImages.m
202 #if __LITTLE_ENDIAN__
203 *(dst + 2) = 0xFF - (p 24 0xFF);
204 *(dst + 1) = 0xFF - (p 16 0xFF);
205 *(dst) = 0xFF - (p 8 0xFF);
206 #else
207 *(dst) = 0xFF - (p 16 0xFF);
208 *(dst + 1) = 0xFF - (p 8 0xFF);
209 *(dst + 2) = 0xFF - (p 0xFF);
210 #endif
211 }
became
217 {
218 *(dst +
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
OK .. it's a step forward, so approved, although there is more to be done.
I do ask that you however restore this comment until you actually remove the
constraint :
405 * - and the destination is opaque
-phil.
On 05/21/2015 07:23 AM, Andrew Brygin wrote:
Hello Phil,
I have changed the default reverse gamma to 180:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/
I also did some experiments with the lcd contrast, and found that
value 160 decreases the discrepancy a bit: 21 instead of 29 with
the default lcd contrast value (140).
However, there still is the discrepancy, and at the moment I do not
see how we can avoid it completely with our rendering model.
It looks like that there is something more sophisticated than
just gamma correction, and we are unable to derive 'color independent'
glyphs from black-on-white glyphs provided by the native system.
I have also played with changing display profiles but it seems to
have no detectable effect.
Thanks,
Andrew
On 5/18/2015 11:19 PM, Phil Race wrote:
Hi,
So 1.79 is essentially 1.8 which is what Mac historically used as
gamma. So I'd pick 180 instead of 179
Since that value minimises the discrepancy it's looking positive but
there's still a discrepancy.
Before we 'live with it', I'd be interested to know what happens if
you set your display's profile to a generic RGB one.
How do the glyph shapes (if you try your best to ignore the colour)
match what other apps produce ?
-phil.
On 04/30/2015 06:21 AM, Andrew Brygin wrote:
Hello Phil,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
The main difference is in glyph generation. I have implemented
'reverse gamma correction'
approach instead of 'glyph blending'. By default we use gamma value
which provides minimum
of discrepancy with gyph images produced by Apple's jdk. However,
it can be adjusted via
environment variable J2D_LCD_REVERSE_GAMMA (CGGlyphImages.m, lines
198 - 220).
Following chart illustrates dependency between the 'reverse gamma'
and a difference
in pixel values comparing to jdk6 from Apple:
http://cr.openjdk.java.net/~bae/8023794/best_reverse_gamma.png
Following set of images has been used for the comparison:
http://cr.openjdk.java.net/~bae/8023794/images/
An index of image corresponds to the value of reverse gamma used
for image
generation.
Beside this, following minor changes were done:
* RenderingHints.KEY_ANTIALIASING was removed form fontHints,
because it has no direct relation to text rendering, and does
not have
any effect at the moment.
* A comment regarding unevaluated rendering hints was added.
Please take a look.
Thanks,
Andrew
On 4/24/2015 7:33 PM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 4/23/2015 11:15 PM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
Why do we need this ? Historically in the (non-OSX) code this
would slow things down by making
text rendering go via ductus rendering.
If this really is a 'fontsHint' map, it seems it should not be here.
I agree that this particular hint has no direct relation to the
font hints,
and probably should not be here. I guess that KEY_ANTALIASING was put
here in order to force text antialiasing on when default text
antailiasing is evaluating:
http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
I do not think that it has any effect now, because we set text
antialiasing hint explicitly.
I will check whether it can be safely removed.
410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE
I thought you were removing this condition ?
I have rolled this change back, because at the moment lcd shader
produces ugly results in the case of translucent destination.
There is a separate bug regarding the translucent destination support:
https://bugs.openjdk.java.net/browse/JDK-8078516
I am going to relax this condition when(if) our lcd shader will be
ready.
In fact, this problem is not limited by ogl, because d3d and
software loops
has the same limitation.
CGGlyphImages.m
202 #if __LITTLE_ENDIAN__
203 *(dst + 2) = 0xFF - (p 24 0xFF);
204 *(dst + 1) = 0xFF - (p 16 0xFF);
205 *(dst) = 0xFF - (p 8 0xFF);
206 #else
207 *(dst) = 0xFF - (p 16 0xFF);
208 *(dst + 1) = 0xFF - (p 8 0xFF);
209 *(dst + 2) = 0xFF - (p 0xFF);
210 #endif
211 }
became
217 {
218 *(dst + 0) = 0xFF - (p 16 0xFF); // red
219 *(dst + 1) = 0xFF - (p 8 0xFF); // green
220 *(dst + 2) = 0xFF - (p 0xFF);// blue
221 }
I started by assuming you were removing the BIG_ENDIAN code that
was probably legacy PPC code but instead I see that the
LITTLE_ENDIAN case is removed,
so I don't understand this.
And further down the file now I see that in
ConvertBWPixelToByteGray you did remove
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello Phil,
I have changed the default reverse gamma to 180:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/
I also did some experiments with the lcd contrast, and found that
value 160 decreases the discrepancy a bit: 21 instead of 29 with
the default lcd contrast value (140).
However, there still is the discrepancy, and at the moment I do not
see how we can avoid it completely with our rendering model.
It looks like that there is something more sophisticated than
just gamma correction, and we are unable to derive 'color independent'
glyphs from black-on-white glyphs provided by the native system.
I have also played with changing display profiles but it seems to
have no detectable effect.
Thanks,
Andrew
On 5/18/2015 11:19 PM, Phil Race wrote:
Hi,
So 1.79 is essentially 1.8 which is what Mac historically used as
gamma. So I'd pick 180 instead of 179
Since that value minimises the discrepancy it's looking positive but
there's still a discrepancy.
Before we 'live with it', I'd be interested to know what happens if
you set your display's profile to a generic RGB one.
How do the glyph shapes (if you try your best to ignore the colour)
match what other apps produce ?
-phil.
On 04/30/2015 06:21 AM, Andrew Brygin wrote:
Hello Phil,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
The main difference is in glyph generation. I have implemented
'reverse gamma correction'
approach instead of 'glyph blending'. By default we use gamma value
which provides minimum
of discrepancy with gyph images produced by Apple's jdk. However, it
can be adjusted via
environment variable J2D_LCD_REVERSE_GAMMA (CGGlyphImages.m, lines
198 - 220).
Following chart illustrates dependency between the 'reverse gamma'
and a difference
in pixel values comparing to jdk6 from Apple:
http://cr.openjdk.java.net/~bae/8023794/best_reverse_gamma.png
Following set of images has been used for the comparison:
http://cr.openjdk.java.net/~bae/8023794/images/
An index of image corresponds to the value of reverse gamma used for
image
generation.
Beside this, following minor changes were done:
* RenderingHints.KEY_ANTIALIASING was removed form fontHints,
because it has no direct relation to text rendering, and does
not have
any effect at the moment.
* A comment regarding unevaluated rendering hints was added.
Please take a look.
Thanks,
Andrew
On 4/24/2015 7:33 PM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 4/23/2015 11:15 PM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
Why do we need this ? Historically in the (non-OSX) code this would
slow things down by making
text rendering go via ductus rendering.
If this really is a 'fontsHint' map, it seems it should not be here.
I agree that this particular hint has no direct relation to the font
hints,
and probably should not be here. I guess that KEY_ANTALIASING was put
here in order to force text antialiasing on when default text
antailiasing is evaluating:
http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
I do not think that it has any effect now, because we set text
antialiasing hint explicitly.
I will check whether it can be safely removed.
410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE
I thought you were removing this condition ?
I have rolled this change back, because at the moment lcd shader
produces ugly results in the case of translucent destination.
There is a separate bug regarding the translucent destination support:
https://bugs.openjdk.java.net/browse/JDK-8078516
I am going to relax this condition when(if) our lcd shader will be
ready.
In fact, this problem is not limited by ogl, because d3d and
software loops
has the same limitation.
CGGlyphImages.m
202 #if __LITTLE_ENDIAN__
203 *(dst + 2) = 0xFF - (p 24 0xFF);
204 *(dst + 1) = 0xFF - (p 16 0xFF);
205 *(dst) = 0xFF - (p 8 0xFF);
206 #else
207 *(dst) = 0xFF - (p 16 0xFF);
208 *(dst + 1) = 0xFF - (p 8 0xFF);
209 *(dst + 2) = 0xFF - (p 0xFF);
210 #endif
211 }
became
217 {
218 *(dst + 0) = 0xFF - (p 16 0xFF); // red
219 *(dst + 1) = 0xFF - (p 8 0xFF); // green
220 *(dst + 2) = 0xFF - (p 0xFF);// blue
221 }
I started by assuming you were removing the BIG_ENDIAN code that
was probably legacy PPC code but instead I see that the
LITTLE_ENDIAN case is removed,
so I don't understand this.
And further down the file now I see that in
ConvertBWPixelToByteGray you did remove the big endian case.
Note that we are
Please note that we force the lcd glyph generation by requesting
host (i.e. LITTLE_ENDIAN) byte order for the canvas bitmap:
407 uint32_t bmpInfo = kCGImageAlphaPremultipliedFirst;
408 if
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hi,
So 1.79 is essentially 1.8 which is what Mac historically used as gamma.
So I'd pick 180 instead of 179
Since that value minimises the discrepancy it's looking positive but
there's still a discrepancy.
Before we 'live with it', I'd be interested to know what happens if you
set your display's profile to a generic RGB one.
How do the glyph shapes (if you try your best to ignore the colour)
match what other apps produce ?
-phil.
On 04/30/2015 06:21 AM, Andrew Brygin wrote:
Hello Phil,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
The main difference is in glyph generation. I have implemented
'reverse gamma correction'
approach instead of 'glyph blending'. By default we use gamma value
which provides minimum
of discrepancy with gyph images produced by Apple's jdk. However, it
can be adjusted via
environment variable J2D_LCD_REVERSE_GAMMA (CGGlyphImages.m, lines
198 - 220).
Following chart illustrates dependency between the 'reverse gamma'
and a difference
in pixel values comparing to jdk6 from Apple:
http://cr.openjdk.java.net/~bae/8023794/best_reverse_gamma.png
Following set of images has been used for the comparison:
http://cr.openjdk.java.net/~bae/8023794/images/
An index of image corresponds to the value of reverse gamma used for
image
generation.
Beside this, following minor changes were done:
* RenderingHints.KEY_ANTIALIASING was removed form fontHints,
because it has no direct relation to text rendering, and does not
have
any effect at the moment.
* A comment regarding unevaluated rendering hints was added.
Please take a look.
Thanks,
Andrew
On 4/24/2015 7:33 PM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 4/23/2015 11:15 PM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
Why do we need this ? Historically in the (non-OSX) code this would
slow things down by making
text rendering go via ductus rendering.
If this really is a 'fontsHint' map, it seems it should not be here.
I agree that this particular hint has no direct relation to the font
hints,
and probably should not be here. I guess that KEY_ANTALIASING was put
here in order to force text antialiasing on when default text
antailiasing is evaluating:
http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
I do not think that it has any effect now, because we set text
antialiasing hint explicitly.
I will check whether it can be safely removed.
410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE
I thought you were removing this condition ?
I have rolled this change back, because at the moment lcd shader
produces ugly results in the case of translucent destination.
There is a separate bug regarding the translucent destination support:
https://bugs.openjdk.java.net/browse/JDK-8078516
I am going to relax this condition when(if) our lcd shader will be
ready.
In fact, this problem is not limited by ogl, because d3d and software
loops
has the same limitation.
CGGlyphImages.m
202 #if __LITTLE_ENDIAN__
203 *(dst + 2) = 0xFF - (p 24 0xFF);
204 *(dst + 1) = 0xFF - (p 16 0xFF);
205 *(dst) = 0xFF - (p 8 0xFF);
206 #else
207 *(dst) = 0xFF - (p 16 0xFF);
208 *(dst + 1) = 0xFF - (p 8 0xFF);
209 *(dst + 2) = 0xFF - (p 0xFF);
210 #endif
211 }
became
217 {
218 *(dst + 0) = 0xFF - (p 16 0xFF); // red
219 *(dst + 1) = 0xFF - (p 8 0xFF); // green
220 *(dst + 2) = 0xFF - (p 0xFF);// blue
221 }
I started by assuming you were removing the BIG_ENDIAN code that
was probably legacy PPC code but instead I see that the
LITTLE_ENDIAN case is removed,
so I don't understand this.
And further down the file now I see that in ConvertBWPixelToByteGray
you did remove the big endian case.
Note that we are
Please note that we force the lcd glyph generation by requesting
host (i.e. LITTLE_ENDIAN) byte order for the canvas bitmap:
407 uint32_t bmpInfo = kCGImageAlphaPremultipliedFirst;
408 if (mode-glyphDescriptor == rgb) {
409 bmpInfo |= kCGBitmapByteOrder32Host;
410 }
So, before the fix (and for grayscale case now) the buffer has default
BIG_ENDIAN order. I.e. grayscale canvas stores data in following format:
as bytes: A R G B
as int: 0xBBGGRRAA
The same byte order was used for the rgb canvas before the fix.
But now the canvas is configured to store data in following format:
as bytes: B G R A
as int: 0xAARRGGBB
So, data extraction routines were updated accordingly.
365 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
366 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
367 default:
368 e = [NSException
369 exceptionWithName:@IllegalArgumentException
370 reason:@Invalid hint value
371
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello Phil,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
The main difference is in glyph generation. I have implemented 'reverse
gamma correction'
approach instead of 'glyph blending'. By default we use gamma value
which provides minimum
of discrepancy with gyph images produced by Apple's jdk. However, it
can be adjusted via
environment variable J2D_LCD_REVERSE_GAMMA (CGGlyphImages.m, lines 198
- 220).
Following chart illustrates dependency between the 'reverse gamma' and
a difference
in pixel values comparing to jdk6 from Apple:
http://cr.openjdk.java.net/~bae/8023794/best_reverse_gamma.png
Following set of images has been used for the comparison:
http://cr.openjdk.java.net/~bae/8023794/images/
An index of image corresponds to the value of reverse gamma used for image
generation.
Beside this, following minor changes were done:
* RenderingHints.KEY_ANTIALIASING was removed form fontHints,
because it has no direct relation to text rendering, and does not have
any effect at the moment.
* A comment regarding unevaluated rendering hints was added.
Please take a look.
Thanks,
Andrew
On 4/24/2015 7:33 PM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 4/23/2015 11:15 PM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
Why do we need this ? Historically in the (non-OSX) code this would
slow things down by making
text rendering go via ductus rendering.
If this really is a 'fontsHint' map, it seems it should not be here.
I agree that this particular hint has no direct relation to the font
hints,
and probably should not be here. I guess that KEY_ANTALIASING was put
here in order to force text antialiasing on when default text
antailiasing is evaluating:
http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
I do not think that it has any effect now, because we set text
antialiasing hint explicitly.
I will check whether it can be safely removed.
410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE
I thought you were removing this condition ?
I have rolled this change back, because at the moment lcd shader
produces ugly results in the case of translucent destination.
There is a separate bug regarding the translucent destination support:
https://bugs.openjdk.java.net/browse/JDK-8078516
I am going to relax this condition when(if) our lcd shader will be ready.
In fact, this problem is not limited by ogl, because d3d and software
loops
has the same limitation.
CGGlyphImages.m
202 #if __LITTLE_ENDIAN__
203 *(dst + 2) = 0xFF - (p 24 0xFF);
204 *(dst + 1) = 0xFF - (p 16 0xFF);
205 *(dst) = 0xFF - (p 8 0xFF);
206 #else
207 *(dst) = 0xFF - (p 16 0xFF);
208 *(dst + 1) = 0xFF - (p 8 0xFF);
209 *(dst + 2) = 0xFF - (p 0xFF);
210 #endif
211 }
became
217 {
218 *(dst + 0) = 0xFF - (p 16 0xFF); // red
219 *(dst + 1) = 0xFF - (p 8 0xFF); // green
220 *(dst + 2) = 0xFF - (p 0xFF);// blue
221 }
I started by assuming you were removing the BIG_ENDIAN code that
was probably legacy PPC code but instead I see that the LITTLE_ENDIAN
case is removed,
so I don't understand this.
And further down the file now I see that in ConvertBWPixelToByteGray
you did remove the big endian case.
Note that we are
Please note that we force the lcd glyph generation by requesting
host (i.e. LITTLE_ENDIAN) byte order for the canvas bitmap:
407 uint32_t bmpInfo = kCGImageAlphaPremultipliedFirst;
408 if (mode-glyphDescriptor == rgb) {
409 bmpInfo |= kCGBitmapByteOrder32Host;
410 }
So, before the fix (and for grayscale case now) the buffer has default
BIG_ENDIAN order. I.e. grayscale canvas stores data in following format:
as bytes: A R G B
as int: 0xBBGGRRAA
The same byte order was used for the rgb canvas before the fix.
But now the canvas is configured to store data in following format:
as bytes: B G R A
as int: 0xAARRGGBB
So, data extraction routines were updated accordingly.
365 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
366 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
367 default:
368 e = [NSException
369 exceptionWithName:@IllegalArgumentException
370 reason:@Invalid hint value
371 userInfo:nil];
I think this means that by the time we get here we should not have
DEFAULT or GASP
but we should have the actual interpretation for this surface, font
and point size.
So this looks correct but maybe you can add a comment on this.
will do.
The heuristic of blending black and white is interesting.
How did you arrive at this ? It suggests that the glyph bitmap we are
caching is
not 'colour neutral' which is odd. Maybe we are missing code to apply
the 'reverse gamma
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello Phil,
please see my comments inline.
On 4/23/2015 11:15 PM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
Why do we need this ? Historically in the (non-OSX) code this would
slow things down by making
text rendering go via ductus rendering.
If this really is a 'fontsHint' map, it seems it should not be here.
I agree that this particular hint has no direct relation to the font hints,
and probably should not be here. I guess that KEY_ANTALIASING was put
here in order to force text antialiasing on when default text
antailiasing is evaluating:
http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
I do not think that it has any effect now, because we set text
antialiasing hint explicitly.
I will check whether it can be safely removed.
410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE
I thought you were removing this condition ?
I have rolled this change back, because at the moment lcd shader
produces ugly results in the case of translucent destination.
There is a separate bug regarding the translucent destination support:
https://bugs.openjdk.java.net/browse/JDK-8078516
I am going to relax this condition when(if) our lcd shader will be ready.
In fact, this problem is not limited by ogl, because d3d and software loops
has the same limitation.
CGGlyphImages.m
202 #if __LITTLE_ENDIAN__
203 *(dst + 2) = 0xFF - (p 24 0xFF);
204 *(dst + 1) = 0xFF - (p 16 0xFF);
205 *(dst) = 0xFF - (p 8 0xFF);
206 #else
207 *(dst) = 0xFF - (p 16 0xFF);
208 *(dst + 1) = 0xFF - (p 8 0xFF);
209 *(dst + 2) = 0xFF - (p 0xFF);
210 #endif
211 }
became
217 {
218 *(dst + 0) = 0xFF - (p 16 0xFF); // red
219 *(dst + 1) = 0xFF - (p 8 0xFF); // green
220 *(dst + 2) = 0xFF - (p 0xFF);// blue
221 }
I started by assuming you were removing the BIG_ENDIAN code that
was probably legacy PPC code but instead I see that the LITTLE_ENDIAN
case is removed,
so I don't understand this.
And further down the file now I see that in ConvertBWPixelToByteGray
you did remove the big endian case.
Note that we are
Please note that we force the lcd glyph generation by requesting
host (i.e. LITTLE_ENDIAN) byte order for the canvas bitmap:
407 uint32_t bmpInfo = kCGImageAlphaPremultipliedFirst;
408 if (mode-glyphDescriptor == rgb) {
409 bmpInfo |= kCGBitmapByteOrder32Host;
410 }
So, before the fix (and for grayscale case now) the buffer has default
BIG_ENDIAN order. I.e. grayscale canvas stores data in following format:
as bytes: A R G B
as int: 0xBBGGRRAA
The same byte order was used for the rgb canvas before the fix.
But now the canvas is configured to store data in following format:
as bytes: B G R A
as int: 0xAARRGGBB
So, data extraction routines were updated accordingly.
365 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
366 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
367 default:
368 e = [NSException
369 exceptionWithName:@IllegalArgumentException
370 reason:@Invalid hint value
371 userInfo:nil];
I think this means that by the time we get here we should not have
DEFAULT or GASP
but we should have the actual interpretation for this surface, font
and point size.
So this looks correct but maybe you can add a comment on this.
will do.
The heuristic of blending black and white is interesting.
How did you arrive at this ? It suggests that the glyph bitmap we are
caching is
not 'colour neutral' which is odd. Maybe we are missing code to apply
the 'reverse gamma correction' ?
I have played with the idea about 'reverse gamma correction', it seemed
very attractive to me.
Roughly speaking, gamma 1 makes black-on-white glyphs a bit narrower,
and white-no-black
glyphs a bit wider (bolder?), and it is the same effect that we need.
Unfortunately, direct comparison of black-on-white and white-on-black
glyphs makes me think
that difference between these glyphs can not be explained only by gamma
correction.
Please take a look at this screenshot:
http://cr.openjdk.java.net/~bae/8023794/bw-wb-comparision.png
http://cr.openjdk.java.net/%7Ebae/8023794/bw-wb-comparision.png
row 1: text is rendered by jdk6 as-is.
row 2: simulates our pipeline where black-on-white glyphs are used (max
error on white-on-black)
row 3: simulates our pipeline where white-on-black glyphs are used (max
error on black-on-white)
row 4: blended glyphs are used.
The basic idea of blending is to minimize max error (difference) between
produced glyph image
and original color-aware glyphs.
If better results can be achieved with 'reverse gamma correction', we
can revise this code later.
And can (should) any of these changes also be applied to D3D ?
1. We can check how gamma correction is done in
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hi Andrew,
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
Why do we need this ? Historically in the (non-OSX) code this would slow things
down by making
text rendering go via ductus rendering.
If this really is a 'fontsHint' map, it seems it should not be here.
410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE
I thought you were removing this condition ?
CGGlyphImages.m
202 #if __LITTLE_ENDIAN__
203 *(dst + 2) = 0xFF - (p 24 0xFF);
204 *(dst + 1) = 0xFF - (p 16 0xFF);
205 *(dst) = 0xFF - (p 8 0xFF);
206 #else
207 *(dst) = 0xFF - (p 16 0xFF);
208 *(dst + 1) = 0xFF - (p 8 0xFF);
209 *(dst + 2) = 0xFF - (p 0xFF);
210 #endif
211 }
became
217 {
218 *(dst + 0) = 0xFF - (p 16 0xFF); // red
219 *(dst + 1) = 0xFF - (p 8 0xFF); // green
220 *(dst + 2) = 0xFF - (p 0xFF);// blue
221 }
I started by assuming you were removing the BIG_ENDIAN code that
was probably legacy PPC code but instead I see that the LITTLE_ENDIAN
case is removed,
so I don't understand this.
And further down the file now I see that in ConvertBWPixelToByteGray you
did remove the big endian case.
365 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
366 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
367 default:
368 e = [NSException
369 exceptionWithName:@IllegalArgumentException
370 reason:@Invalid hint value
371 userInfo:nil];
I think this means that by the time we get here we should not have
DEFAULT or GASP
but we should have the actual interpretation for this surface, font and
point size.
So this looks correct but maybe you can add a comment on this.
The heuristic of blending black and white is interesting.
How did you arrive at this ? It suggests that the glyph bitmap we are
caching is
not 'colour neutral' which is odd. Maybe we are missing code to apply
the 'reverse gamma correction' ?
And can (should) any of these changes also be applied to D3D ?
-phil.
On 03/27/2015 07:50 AM, Andrew Brygin wrote:
There is a minor update in the fix: it does not worth to blend
black-on-white
and white-on-black glyphs for the case of AA glyphs, because it makes
no difference.
CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.08
I have also modified the AntialiasDemo a bit in order to render the
sample text in different colors, and in order to render into a volatile
image as well:
http://cr.openjdk.java.net/~bae/8023794/demo/AntialiasDemo.java
It could be used to assess the change in glyph generation.
Thanks,
Andrew
On 3/26/2015 3:59 PM, Andrew Brygin wrote:
Hi Chris,
thank you for the comments and explanation. I have updated the
OGLContext_IsLCDShaderSupportAvailable()
and comments in OGLTextRenderer.c accordingly:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/
Good to know that you keep an eye on the OGL pipeline :)
Thanks,
Andrew
On 3/25/2015 8:24 PM, Chris Campbell wrote:
Hi Andrew,
That's a good find re: pow(). In the comment at lines 277-283 I
mentioned that there was only a scalar variant of pow(). I wonder
if that was a limitation in some early version of GLSL I was using
or perhaps some driver bug/restriction. According to all the docs I
can find the vector variants have been there all along:
https://www.opengl.org/sdk/docs/man4/index.php
So now I'm wondering if the slowness was actually due to me trying 3
scalar pow() calls versus one vector pow() call.
Oh, aha! I think this explains part of it:
269 * This is the GLSL fragment shader source code for rendering
LCD-optimized
270 * text. Do not be frightened; it is much easier to understand
than the
271 * equivalent ASM-like fragment program!
Looks like I wrote the original version of this shader using the
GL_ARB_fragment_program language, which indeed only had a scalar POW
instruction (see section 3.11.5.20):
https://www.opengl.org/registry/specs/ARB/fragment_program.txt
And then I'm guessing that when I rewrote it in more modern GLSL, I
didn't notice that pow() supported vectors. Sigh. That 3D texture
LUT was a lot of work for a whole lot of nothing.
In any case, you might want to rewrite the comment at lines 277-283
to suit the new code. Same goes for the comment at line 315:
// gamma adjust the dest color using the invgamma LUT
Also, I noticed that the restrictions in
OGLContext_IsLCDShaderSupportAvailable() could be loosened since you
only need 2 texture units now. Just in the extremely unlikely case
that anyone's running this stuff on ancient hardware :)
Thanks,
Chris
Andrew Brygin wrote:
Hello Phil,
could you please take a look to updated version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
* OGLTextRenderer.c
It was discovered, that in some cases lcd glyphs had visible 'dark
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
The fix looks fine to me. It will be good if an SQE team will port this test to the jdk ws. On 27.03.15 17:50, Andrew Brygin wrote: There is a minor update in the fix: it does not worth to blend black-on-white and white-on-black glyphs for the case of AA glyphs, because it makes no difference. CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794: http://cr.openjdk.java.net/~bae/8023794/9/webrev.08 I have also modified the AntialiasDemo a bit in order to render the sample text in different colors, and in order to render into a volatile image as well: http://cr.openjdk.java.net/~bae/8023794/demo/AntialiasDemo.java It could be used to assess the change in glyph generation. Thanks, Andrew On 3/26/2015 3:59 PM, Andrew Brygin wrote: Hi Chris, thank you for the comments and explanation. I have updated the OGLContext_IsLCDShaderSupportAvailable() and comments in OGLTextRenderer.c accordingly: http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/ Good to know that you keep an eye on the OGL pipeline :) Thanks, Andrew On 3/25/2015 8:24 PM, Chris Campbell wrote: Hi Andrew, That's a good find re: pow(). In the comment at lines 277-283 I mentioned that there was only a scalar variant of pow(). I wonder if that was a limitation in some early version of GLSL I was using or perhaps some driver bug/restriction. According to all the docs I can find the vector variants have been there all along: https://www.opengl.org/sdk/docs/man4/index.php So now I'm wondering if the slowness was actually due to me trying 3 scalar pow() calls versus one vector pow() call. Oh, aha! I think this explains part of it: 269 * This is the GLSL fragment shader source code for rendering LCD-optimized 270 * text. Do not be frightened; it is much easier to understand than the 271 * equivalent ASM-like fragment program! Looks like I wrote the original version of this shader using the GL_ARB_fragment_program language, which indeed only had a scalar POW instruction (see section 3.11.5.20): https://www.opengl.org/registry/specs/ARB/fragment_program.txt And then I'm guessing that when I rewrote it in more modern GLSL, I didn't notice that pow() supported vectors. Sigh. That 3D texture LUT was a lot of work for a whole lot of nothing. In any case, you might want to rewrite the comment at lines 277-283 to suit the new code. Same goes for the comment at line 315: // gamma adjust the dest color using the invgamma LUT Also, I noticed that the restrictions in OGLContext_IsLCDShaderSupportAvailable() could be loosened since you only need 2 texture units now. Just in the extremely unlikely case that anyone's running this stuff on ancient hardware :) Thanks, Chris Andrew Brygin wrote: Hello Phil, could you please take a look to updated version of the fix? http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/ * OGLTextRenderer.c It was discovered, that in some cases lcd glyphs had visible 'dark border' around. This border appeared due to the gamma correction in lcd shader, which uses lookup on 3D texture instead of using 'pow' routine. The texture is populated with significant granularity (16 points per edge), what is a root cause of rough interpolation of color values. Suggested change is to eliminate the interpolation and use 'pow' routine directly. It gives more accurate color values, and does not introduce significant performance hit (see benchmark summary below). However, this part of the fix affects not only macosx, but any platform where OGL text shader can be used, so it probably worth to split into a separate fix. Summary: lcd-ogl-3Dlookup: Number of tests: 4 Overall average: 42.68027553311743 Best spread: 3.49% variance Worst spread: 29.59% variance (Basis for results comparison) lcd-ogl-pow: Number of tests: 4 Overall average: 42.468941501367084 Best spread: 2.51% variance Worst spread: 29.44% variance Comparison to basis: Best result: 103.28% of basis Worst result: 97.36% of basis Number of wins: 1 Number of ties: 2 Number of losses: 1 Thanks, Andrew -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
There is a minor update in the fix: it does not worth to blend black-on-white and white-on-black glyphs for the case of AA glyphs, because it makes no difference. CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794: http://cr.openjdk.java.net/~bae/8023794/9/webrev.08 I have also modified the AntialiasDemo a bit in order to render the sample text in different colors, and in order to render into a volatile image as well: http://cr.openjdk.java.net/~bae/8023794/demo/AntialiasDemo.java It could be used to assess the change in glyph generation. Thanks, Andrew On 3/26/2015 3:59 PM, Andrew Brygin wrote: Hi Chris, thank you for the comments and explanation. I have updated the OGLContext_IsLCDShaderSupportAvailable() and comments in OGLTextRenderer.c accordingly: http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/ Good to know that you keep an eye on the OGL pipeline :) Thanks, Andrew On 3/25/2015 8:24 PM, Chris Campbell wrote: Hi Andrew, That's a good find re: pow(). In the comment at lines 277-283 I mentioned that there was only a scalar variant of pow(). I wonder if that was a limitation in some early version of GLSL I was using or perhaps some driver bug/restriction. According to all the docs I can find the vector variants have been there all along: https://www.opengl.org/sdk/docs/man4/index.php So now I'm wondering if the slowness was actually due to me trying 3 scalar pow() calls versus one vector pow() call. Oh, aha! I think this explains part of it: 269 * This is the GLSL fragment shader source code for rendering LCD-optimized 270 * text. Do not be frightened; it is much easier to understand than the 271 * equivalent ASM-like fragment program! Looks like I wrote the original version of this shader using the GL_ARB_fragment_program language, which indeed only had a scalar POW instruction (see section 3.11.5.20): https://www.opengl.org/registry/specs/ARB/fragment_program.txt And then I'm guessing that when I rewrote it in more modern GLSL, I didn't notice that pow() supported vectors. Sigh. That 3D texture LUT was a lot of work for a whole lot of nothing. In any case, you might want to rewrite the comment at lines 277-283 to suit the new code. Same goes for the comment at line 315: // gamma adjust the dest color using the invgamma LUT Also, I noticed that the restrictions in OGLContext_IsLCDShaderSupportAvailable() could be loosened since you only need 2 texture units now. Just in the extremely unlikely case that anyone's running this stuff on ancient hardware :) Thanks, Chris Andrew Brygin wrote: Hello Phil, could you please take a look to updated version of the fix? http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/ * OGLTextRenderer.c It was discovered, that in some cases lcd glyphs had visible 'dark border' around. This border appeared due to the gamma correction in lcd shader, which uses lookup on 3D texture instead of using 'pow' routine. The texture is populated with significant granularity (16 points per edge), what is a root cause of rough interpolation of color values. Suggested change is to eliminate the interpolation and use 'pow' routine directly. It gives more accurate color values, and does not introduce significant performance hit (see benchmark summary below). However, this part of the fix affects not only macosx, but any platform where OGL text shader can be used, so it probably worth to split into a separate fix. Summary: lcd-ogl-3Dlookup: Number of tests: 4 Overall average: 42.68027553311743 Best spread: 3.49% variance Worst spread: 29.59% variance (Basis for results comparison) lcd-ogl-pow: Number of tests: 4 Overall average: 42.468941501367084 Best spread: 2.51% variance Worst spread: 29.44% variance Comparison to basis: Best result: 103.28% of basis Worst result: 97.36% of basis Number of wins: 1 Number of ties: 2 Number of losses: 1 Thanks, Andrew
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello Phil, could you please take a look to updated version of the fix? http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/ * CGGlyphImages.m The main part of the recent changes is related to generation of LCD glyph images. With previous version of the fix we produced lcd glyphs which were quite close to jdk6 results if we render dark text on light background (black on white as an extreme case). However, it was discovered that in the case of light text on dark background, our results had significant differences comparing with jdk6. In order to reduce the difference, now we produce two separate glyph images (black-on-white and white-on-black), blend them, and then pass the blended glyph image to text pipes. This approach seems to give an acceptable results for both light and dark cases. * OGLTextRenderer.c It was discovered, that in some cases lcd glyphs had visible 'dark border' around. This border appeared due to the gamma correction in lcd shader, which uses lookup on 3D texture instead of using 'pow' routine. The texture is populated with significant granularity (16 points per edge), what is a root cause of rough interpolation of color values. Suggested change is to eliminate the interpolation and use 'pow' routine directly. It gives more accurate color values, and does not introduce significant performance hit (see benchmark summary below). However, this part of the fix affects not only macosx, but any platform where OGL text shader can be used, so it probably worth to split into a separate fix. Summary: lcd-ogl-3Dlookup: Number of tests: 4 Overall average: 42.68027553311743 Best spread: 3.49% variance Worst spread: 29.59% variance (Basis for results comparison) lcd-ogl-pow: Number of tests: 4 Overall average: 42.468941501367084 Best spread: 2.51% variance Worst spread: 29.44% variance Comparison to basis: Best result: 103.28% of basis Worst result: 97.36% of basis Number of wins: 1 Number of ties: 2 Number of losses: 1 Thanks, Andrew On 12/12/2014 8:11 PM, Andrew Brygin wrote: Hello Phil, at the moment, I failed to get acceptable results for rendering to translucent destination. I am playing with an idea to fall back to grayscale AA on non-opaque pixels (or pixels with opacity less than a certain threshold) directly in the lcd shader program. For now, there is an updated version of the fix which supports lcd text in OGL pipeline for a case of alpha paint and default composite. However, the case of translucent destination is not supported yet, that makes lcd text unavailable in swing apps on macosx. All changes specific for this version are in OGLSurfaceData.java and OGLTextRenderer.c. Rest of the fix is unchanged. http://cr.openjdk.java.net/~bae/8023794/9/webrev.04/ Of course, this version may affect the performance of lcd text rendering, but I have no numbers to estimate the effect at the moment. In the worst case, we can consider to use two different programs: one for opaque paint (in order to preserve performance), and another (like published now) for the case of alpha paint. Please take a look. Thanks, Andrew On 10/25/2014 12:03 AM, Phil Race wrote: On 10/24/2014 10:56 AM, Andrew Brygin wrote: Hello, please take a look to updated version of the fix: http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/ TODOs were removed: * CGLSurfaceData.java the condition for lcd rendering is inherited from OGL surface data, but here we have to remove the check for the transparency, because we always create transparent volatile images for swing backbuffers on macosx in order to support shaped windows. Are you saying its created translucent regardless, or only if its shaped? But if its really translucent/transparent under the text, then IIRC the shaders - and s/w loops - do not properly handle that case. You probably should try drawing LCD text over a fully transparent area to see what happens. * * *CGGlyphImages.m and AWTStrike.m NSException is used to handle invalid (unevaluated) text antialising hint values. We actually have already used NSException to handle memory allocation failure, so this change just makes usage of get/release of primitive arrays a bit more safe. Known differences comparing to apple jdk6: a) we do not interpret TEXT_ANTIALIASING_ON as lcd text. Its should never have meant that, else you would have no way to explicitly request grey scale. b) we do not render lcd text in a case of non-opaque paint. This behavior is common for all cases (software loops, OGL, and D3D), so it seems to deserve a separate bug if we want to handle this case. I think that's another manifestation of the issue mentioned above. -phil.
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hi Andrew, That's a good find re: pow(). In the comment at lines 277-283 I mentioned that there was only a scalar variant of pow(). I wonder if that was a limitation in some early version of GLSL I was using or perhaps some driver bug/restriction. According to all the docs I can find the vector variants have been there all along: https://www.opengl.org/sdk/docs/man4/index.php So now I'm wondering if the slowness was actually due to me trying 3 scalar pow() calls versus one vector pow() call. Oh, aha! I think this explains part of it: 269 * This is the GLSL fragment shader source code for rendering LCD-optimized 270 * text. Do not be frightened; it is much easier to understand than the 271 * equivalent ASM-like fragment program! Looks like I wrote the original version of this shader using the GL_ARB_fragment_program language, which indeed only had a scalar POW instruction (see section 3.11.5.20): https://www.opengl.org/registry/specs/ARB/fragment_program.txt And then I'm guessing that when I rewrote it in more modern GLSL, I didn't notice that pow() supported vectors. Sigh. That 3D texture LUT was a lot of work for a whole lot of nothing. In any case, you might want to rewrite the comment at lines 277-283 to suit the new code. Same goes for the comment at line 315: // gamma adjust the dest color using the invgamma LUT Also, I noticed that the restrictions in OGLContext_IsLCDShaderSupportAvailable() could be loosened since you only need 2 texture units now. Just in the extremely unlikely case that anyone's running this stuff on ancient hardware :) Thanks, Chris Andrew Brygin wrote: Hello Phil, could you please take a look to updated version of the fix? http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/ * OGLTextRenderer.c It was discovered, that in some cases lcd glyphs had visible 'dark border' around. This border appeared due to the gamma correction in lcd shader, which uses lookup on 3D texture instead of using 'pow' routine. The texture is populated with significant granularity (16 points per edge), what is a root cause of rough interpolation of color values. Suggested change is to eliminate the interpolation and use 'pow' routine directly. It gives more accurate color values, and does not introduce significant performance hit (see benchmark summary below). However, this part of the fix affects not only macosx, but any platform where OGL text shader can be used, so it probably worth to split into a separate fix. Summary: lcd-ogl-3Dlookup: Number of tests: 4 Overall average: 42.68027553311743 Best spread: 3.49% variance Worst spread: 29.59% variance (Basis for results comparison) lcd-ogl-pow: Number of tests: 4 Overall average: 42.468941501367084 Best spread: 2.51% variance Worst spread: 29.44% variance Comparison to basis: Best result: 103.28% of basis Worst result: 97.36% of basis Number of wins: 1 Number of ties: 2 Number of losses: 1 Thanks, Andrew
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello Phil, at the moment, I failed to get acceptable results for rendering to translucent destination. I am playing with an idea to fall back to grayscale AA on non-opaque pixels (or pixels with opacity less than a certain threshold) directly in the lcd shader program. For now, there is an updated version of the fix which supports lcd text in OGL pipeline for a case of alpha paint and default composite. However, the case of translucent destination is not supported yet, that makes lcd text unavailable in swing apps on macosx. All changes specific for this version are in OGLSurfaceData.java and OGLTextRenderer.c. Rest of the fix is unchanged. http://cr.openjdk.java.net/~bae/8023794/9/webrev.04/ Of course, this version may affect the performance of lcd text rendering, but I have no numbers to estimate the effect at the moment. In the worst case, we can consider to use two different programs: one for opaque paint (in order to preserve performance), and another (like published now) for the case of alpha paint. Please take a look. Thanks, Andrew On 10/25/2014 12:03 AM, Phil Race wrote: On 10/24/2014 10:56 AM, Andrew Brygin wrote: Hello, please take a look to updated version of the fix: http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/ TODOs were removed: * CGLSurfaceData.java the condition for lcd rendering is inherited from OGL surface data, but here we have to remove the check for the transparency, because we always create transparent volatile images for swing backbuffers on macosx in order to support shaped windows. Are you saying its created translucent regardless, or only if its shaped? But if its really translucent/transparent under the text, then IIRC the shaders - and s/w loops - do not properly handle that case. You probably should try drawing LCD text over a fully transparent area to see what happens. * * *CGGlyphImages.m and AWTStrike.m NSException is used to handle invalid (unevaluated) text antialising hint values. We actually have already used NSException to handle memory allocation failure, so this change just makes usage of get/release of primitive arrays a bit more safe. Known differences comparing to apple jdk6: a) we do not interpret TEXT_ANTIALIASING_ON as lcd text. Its should never have meant that, else you would have no way to explicitly request grey scale. b) we do not render lcd text in a case of non-opaque paint. This behavior is common for all cases (software loops, OGL, and D3D), so it seems to deserve a separate bug if we want to handle this case. I think that's another manifestation of the issue mentioned above. -phil.
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hi Andrew,
I have added an OpenGL view in the project just to illustrate that OpenGL
provides exactly the same results.
I also wrote a simple test the results are below
http://i.imgur.com/cEt6HYo.png http://i.imgur.com/cEt6HYo.png
The letters are written with the same font and the same size
From left to right
1. Panel Graphics
2. BufferedImage Graphics - Panel Graphics
3. NSView
4. CGImageRef - NSView
5. CGImageRef - OpenGL
1,3,5 give the same results
2,4 are give the same results but a little bit brighter than 1,3,5
I would prefer more consistent results. But again I am not sure how to handle
this. Might be we should use some kind of “compatible context” and proper
colorspace.
Thank you,
Denis.
Looks like the same
On 05 Nov 2014, at 16:57, Denis S. Fokin denis.fo...@gmail.com wrote:
Hi Andrew,
I have noticed an issue with quartz (at list with our way to use it).
This is a simple project that allows to illustrate the issue with a pure
Quartz and Cocoa.
https://github.com/denis-fokin/OffscreenVsQuartzFontRendering
https://github.com/denis-fokin/OffscreenVsQuartzFontRendering
Below you can see results.
I used the same MBP with an external Thunderbolt display.
Rendering of a glyph in the view and in the offscreen bitmap is the same for
non-retina display.
http://imgur.com/Y33C0tF,vnn5Ajt#0 http://imgur.com/Y33C0tF,vnn5Ajt#0
In case of retina, it seems that the image uses improper number of pixels.
http://imgur.com/Y33C0tF,vnn5Ajt#1 http://imgur.com/Y33C0tF,vnn5Ajt#1
I see the same effect in the java-2d sub pixel rendering implementation.
Right now I am not sure, how to handle this properly.
Thank you,
Denis.
On 24 Oct 2014, at 21:56, Andrew Brygin andrew.bry...@oracle.com
mailto:andrew.bry...@oracle.com wrote:
Hello,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/
http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/
TODOs were removed:
* CGLSurfaceData.java
the condition for lcd rendering is inherited from OGL surface data, but
here we have to remove the check for the transparency, because we
always
create transparent volatile images for swing backbuffers on macosx in
order
to support shaped windows.
* CGGlyphImages.m and AWTStrike.m
NSException is used to handle invalid (unevaluated) text antialising
hint values.
We actually have already used NSException to handle memory allocation
failure,
so this change just makes usage of get/release of primitive arrays a
bit more safe.
Known differences comparing to apple jdk6:
a) we do not interpret TEXT_ANTIALIASING_ON as lcd text.
b) we do not render lcd text in a case of non-opaque paint. This behavior is
common for
all cases (software loops, OGL, and D3D), so it seems to deserve a
separate bug if we
want to handle this case.
Thanks,
Andrew
On 10/14/2014 3:39 AM, Phil Race wrote:
On 10/13/2014 05:41 AM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 10/13/2014 12:05 AM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
374 fontHints.put(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HBGR);
I am not sure why we have the graphics AA hint ON set here.
Its not truly a font hint even though if its set it implcitly triggers
font AA to be on too.
If you remove that first line do you notice any problems with Swing apps ?
I failed to spot any difference in the SwingSet2 demo after removal the
line 373.
Hmm .. Sergey seemed to suggest it was needed.
I was concerned that it might subvert the text rendering hint
as it used to cause us to do everything via the graphics AA loops.
So I guess I am not sure what the impact of removing it will be
You probably should check if it changes Metal Nimbus rendering
in SwingSet as it looks to be read by those but I don't see anywhere
Aqua is reading these hints which is puzzling as you'd think that's
where they were wanted.
The logic in the following code looks odd to me ..
310 static CGGI_GlyphInfoDescriptor grey =
311 { 1, CGGI_CopyImageFromCanvasToAlphaInfo };
312 static CGGI_GlyphInfoDescriptor rgb =
313 { 3, CGGI_CopyImageFromCanvasToRGBInfo };
314
315 static inline CGGI_RenderingMode
316 CGGI_GetRenderingMode(const AWTStrike *strike)
317 {
318 CGGI_RenderingMode mode;
319 mode.cgFontMode = strike-fStyle;
320
321 switch (strike-fAAStyle) {
322 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_OFF:
323 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_ON:
324 mode.glyphDescriptor = grey;
325 break;
326 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HRGB:
327 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HBGR:
328 case
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hi Andrew,
I have noticed an issue with quartz (at list with our way to use it).
This is a simple project that allows to illustrate the issue with a pure Quartz
and Cocoa.
https://github.com/denis-fokin/OffscreenVsQuartzFontRendering
https://github.com/denis-fokin/OffscreenVsQuartzFontRendering
Below you can see results.
I used the same MBP with an external Thunderbolt display.
Rendering of a glyph in the view and in the offscreen bitmap is the same for
non-retina display.
http://imgur.com/Y33C0tF,vnn5Ajt#0 http://imgur.com/Y33C0tF,vnn5Ajt#0
In case of retina, it seems that the image uses improper number of pixels.
http://imgur.com/Y33C0tF,vnn5Ajt#1 http://imgur.com/Y33C0tF,vnn5Ajt#1
I see the same effect in the java-2d sub pixel rendering implementation.
Right now I am not sure, how to handle this properly.
Thank you,
Denis.
On 24 Oct 2014, at 21:56, Andrew Brygin andrew.bry...@oracle.com wrote:
Hello,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/
http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/
TODOs were removed:
* CGLSurfaceData.java
the condition for lcd rendering is inherited from OGL surface data, but
here we have to remove the check for the transparency, because we always
create transparent volatile images for swing backbuffers on macosx in
order
to support shaped windows.
* CGGlyphImages.m and AWTStrike.m
NSException is used to handle invalid (unevaluated) text antialising
hint values.
We actually have already used NSException to handle memory allocation
failure,
so this change just makes usage of get/release of primitive arrays a
bit more safe.
Known differences comparing to apple jdk6:
a) we do not interpret TEXT_ANTIALIASING_ON as lcd text.
b) we do not render lcd text in a case of non-opaque paint. This behavior is
common for
all cases (software loops, OGL, and D3D), so it seems to deserve a
separate bug if we
want to handle this case.
Thanks,
Andrew
On 10/14/2014 3:39 AM, Phil Race wrote:
On 10/13/2014 05:41 AM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 10/13/2014 12:05 AM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
374 fontHints.put(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HBGR);
I am not sure why we have the graphics AA hint ON set here.
Its not truly a font hint even though if its set it implcitly triggers
font AA to be on too.
If you remove that first line do you notice any problems with Swing apps ?
I failed to spot any difference in the SwingSet2 demo after removal the
line 373.
Hmm .. Sergey seemed to suggest it was needed.
I was concerned that it might subvert the text rendering hint
as it used to cause us to do everything via the graphics AA loops.
So I guess I am not sure what the impact of removing it will be
You probably should check if it changes Metal Nimbus rendering
in SwingSet as it looks to be read by those but I don't see anywhere
Aqua is reading these hints which is puzzling as you'd think that's
where they were wanted.
The logic in the following code looks odd to me ..
310 static CGGI_GlyphInfoDescriptor grey =
311 { 1, CGGI_CopyImageFromCanvasToAlphaInfo };
312 static CGGI_GlyphInfoDescriptor rgb =
313 { 3, CGGI_CopyImageFromCanvasToRGBInfo };
314
315 static inline CGGI_RenderingMode
316 CGGI_GetRenderingMode(const AWTStrike *strike)
317 {
318 CGGI_RenderingMode mode;
319 mode.cgFontMode = strike-fStyle;
320
321 switch (strike-fAAStyle) {
322 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_OFF:
323 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_ON:
324 mode.glyphDescriptor = grey;
325 break;
326 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HRGB:
327 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HBGR:
328 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VRGB:
329 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VBGR:
330 mode.glyphDescriptor = rgb;
331 break;
332 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
333 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
334 default:
335 // TODO: generate an error?
336 break;
337 }
.. If we get to default does this mean aliased rendering ?
If so why would OFF go the grey path - seems it should go default
And GASP looks like there is no support to specify the intended meaning
there
Given that OS X text is unhinted I'd think ON is a better option here
even though most fonts would do OFF at typical screen sizes .. but that's
because they are expecting hinted rendering. So I think you need to get
hinted glyphs to default this to aliased ..
If my understanding is
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello,
please take a look to updated version of the fix:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/
TODOs were removed:
* CGLSurfaceData.java
the condition for lcd rendering is inherited from OGL surface
data, but
here we have to remove the check for the transparency, because we
always
create transparent volatile images for swing backbuffers on
macosx in order
to support shaped windows.
* * *CGGlyphImages.m and AWTStrike.m
NSException is used to handle invalid (unevaluated) text
antialising hint values.
We actually have already used NSException to handle memory
allocation failure,
so this change just makes usage of get/release of primitive
arrays a bit more safe.
Known differences comparing to apple jdk6:
a) we do not interpret TEXT_ANTIALIASING_ON as lcd text.
b) we do not render lcd text in a case of non-opaque paint. This
behavior is common for
all cases (software loops, OGL, and D3D), so it seems to deserve a
separate bug if we
want to handle this case.
Thanks,
Andrew
On 10/14/2014 3:39 AM, Phil Race wrote:
On 10/13/2014 05:41 AM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 10/13/2014 12:05 AM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
374 fontHints.put(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HBGR);
I am not sure why we have the graphics AA hint ON set here.
Its not truly a font hint even though if its set it implcitly triggers font AA
to be on too.
If you remove that first line do you notice any problems with Swing apps ?
I failed to spot any difference in the SwingSet2 demo after removal
the line 373.
Hmm .. Sergey seemed to suggest it was needed.
I was concerned that it might subvert the text rendering hint
as it used to cause us to do everything via the graphics AA loops.
So I guess I am not sure what the impact of removing it will be
You probably should check if it changes Metal Nimbus rendering
in SwingSet as it looks to be read by those but I don't see anywhere
Aqua is reading these hints which is puzzling as you'd think that's
where they were wanted.
The logic in the following code looks odd to me ..
310 static CGGI_GlyphInfoDescriptor grey =
311 { 1, CGGI_CopyImageFromCanvasToAlphaInfo };
312 static CGGI_GlyphInfoDescriptor rgb =
313 { 3, CGGI_CopyImageFromCanvasToRGBInfo };
314
315 static inline CGGI_RenderingMode
316 CGGI_GetRenderingMode(const AWTStrike *strike)
317 {
318 CGGI_RenderingMode mode;
319 mode.cgFontMode = strike-fStyle;
320
321 switch (strike-fAAStyle) {
322 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_OFF:
323 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_ON:
324 mode.glyphDescriptor = grey;
325 break;
326 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HRGB:
327 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HBGR:
328 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VRGB:
329 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VBGR:
330 mode.glyphDescriptor = rgb;
331 break;
332 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
333 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
334 default:
335 // TODO: generate an error?
336 break;
337 }
.. If we get to default does this mean aliased rendering ?
If so why would OFF go the grey path - seems it should go default
And GASP looks like there is no support to specify the intended
meaning there
Given that OS X text is unhinted I'd think ON is a better option here
even though most fonts would do OFF at typical screen sizes .. but
that's
because they are expecting hinted rendering. So I think you need to get
hinted glyphs to default this to aliased ..
If my understanding is correct, we never get TEXT_ANTIALIAS_GASP and
TEXT_ANTIALIAS_DEFAULT here, because these hints must be already
evaluated
and translated to either TEXT_ANTIALIAS_OFF, or TEXT_ANTIALIAS_ON.
It should be done in SunGraphisc2D.checkFontInfo(), lines 699 - 775.
this is probably right so its OK ..
-phil.
At this point we have no enough info to evaluate these hints properly,
and a best solution is probably to raise an error.
Thanks,
Andrew
-phil.
On 10/10/14 2:13 PM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 10/11/2014 12:49 AM, Phil Race wrote:
On 10/10/14 11:05 AM, Andrew Brygin wrote:
Hello Phil,
changes in SunGraphics2D and SurfaceData were made in order to
implement an approach 'LCD instead of greyscale AA if possible'.
Without this part of change, we get results according to the hints:
greyscale for TEXT_ANTIALIAS_ON, and subpixels for lcd hints:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.01/
So you are changing the meaning of application-specified ON
across platforms ?
That sounds wrong
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
On 10/24/2014 10:56 AM, Andrew Brygin wrote: Hello, please take a look to updated version of the fix: http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/ TODOs were removed: * CGLSurfaceData.java the condition for lcd rendering is inherited from OGL surface data, but here we have to remove the check for the transparency, because we always create transparent volatile images for swing backbuffers on macosx in order to support shaped windows. Are you saying its created translucent regardless, or only if its shaped? But if its really translucent/transparent under the text, then IIRC the shaders - and s/w loops - do not properly handle that case. You probably should try drawing LCD text over a fully transparent area to see what happens. * * *CGGlyphImages.m and AWTStrike.m NSException is used to handle invalid (unevaluated) text antialising hint values. We actually have already used NSException to handle memory allocation failure, so this change just makes usage of get/release of primitive arrays a bit more safe. Known differences comparing to apple jdk6: a) we do not interpret TEXT_ANTIALIASING_ON as lcd text. Its should never have meant that, else you would have no way to explicitly request grey scale. b) we do not render lcd text in a case of non-opaque paint. This behavior is common for all cases (software loops, OGL, and D3D), so it seems to deserve a separate bug if we want to handle this case. I think that's another manifestation of the issue mentioned above. -phil.
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hi, Phil.
I guess that on osx defaults were changed to something more modern long time
ago. Including all types of rendering. In jdk6 it was done in the graphics
itself, but during macport the decision not to change SG2D was made, but use
DesktopProperty instead.
It demanded changes in Aqua LaF, which was changed to use
SwingUtilities2.drawString instead of g.drawString.
http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/55b73c5d1c93
Interesting is that in this time HRGB(which did not work) was changed to ON.
http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/e45f5175d849
- philip.r...@oracle.com wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON); 374
fontHints.put(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HBGR);
I am not sure why we have the graphics AA hint ON set here.
Its not truly a font hint even though if its set it implcitly triggers font AA
to be on too.
If you remove that first line do you notice any problems with Swing apps ?
The logic in the following code looks odd to me ..
310 static CGGI_GlyphInfoDescriptor grey =
311 { 1, CGGI_CopyImageFromCanvasToAlphaInfo };
312 static CGGI_GlyphInfoDescriptor rgb =
313 { 3, CGGI_CopyImageFromCanvasToRGBInfo };
314
315 static inline CGGI_RenderingMode
316 CGGI_GetRenderingMode(const AWTStrike *strike)
317 {
318 CGGI_RenderingMode mode;
319 mode.cgFontMode = strike-fStyle;
320
321 switch (strike-fAAStyle) {
322 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_OFF:
323 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_ON:
324 mode.glyphDescriptor = grey;
325 break;
326 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HRGB:
327 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HBGR:
328 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VRGB:
329 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VBGR:
330 mode.glyphDescriptor = rgb;
331 break; 332 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
333 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT: 334 default:
335 // TODO: generate an error? 336 break; 337 }
.. If we get to default does this mean aliased rendering ?
If so why would OFF go the grey path - seems it should go default
And GASP looks like there is no support to specify the intended meaning
there
Given that OS X text is unhinted I'd think ON is a better option here
even though most fonts would do OFF at typical screen sizes .. but that's
because they are expecting hinted rendering. So I think you need to get
hinted glyphs to default this to aliased ..
-phil.
On 10/10/14 2:13 PM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 10/11/2014 12:49 AM, Phil Race wrote:
On 10/10/14 11:05 AM, Andrew Brygin wrote:
Hello Phil,
changes in SunGraphics2D and SurfaceData were made in order to
implement an approach 'LCD instead of greyscale AA if possible'.
Without this part of change, we get results according to the hints:
greyscale for TEXT_ANTIALIAS_ON, and subpixels for lcd hints:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.01/
So you are changing the meaning of application-specified ON across
platforms ?
That sounds wrong - even for Mac ...
now I do not: the fix revision 01 does not change the meaning of the hints,
and just makes text rendering on macosx to behave in a similar manner as
on windows.
Please take a look at the webrev.01.
Thanks,
Andrew
I am not sure whether do we need to change the 'default'
behavior: at the moment it produces aliased text.
default has meant aliased in all the non-mac sun/oracle implementations
since JDK 1.2. We have talked about changing it to something
more modern but should not do it lightly ..
-phil.
Thanks,
Andrew
On 10/10/2014 8:54 PM, Phil Race wrote:
I don't have my head around all these changes but a lot of it seems to
imply we really weren't asking for LCDon Mac when we could/should.
The change in the shared SurfaceData.javais something I want to
ask about as you have commented out as follows ..
;
749 750 // TODO: we have to take into account aaHint on macosx 751
//case SunHints.INTVAL_TEXT_ANTIALIAS_ON: 752 //return
aaTextRenderer;
...
that looks like the case where the application code has *explicitly*
specified greyscale (ON==greyscale) so I don't see why you need
to go check the fontinfo in this case ?
-phil.
On 10/10/2014 07:34 AM, Andrew Brygin wrote:
Hello Denis,
could you please take a look at a preliminary version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/
This fix promotes the text antialiasing from grayscale to LCD if
destination surface data is able to render LCD, and provides
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello Phil,
please see my comments inline.
On 10/13/2014 12:05 AM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
374 fontHints.put(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HBGR);
I am not sure why we have the graphics AA hint ON set here.
Its not truly a font hint even though if its set it implcitly triggers font AA
to be on too.
If you remove that first line do you notice any problems with Swing apps ?
I failed to spot any difference in the SwingSet2 demo after removal the
line 373.
The logic in the following code looks odd to me ..
310 static CGGI_GlyphInfoDescriptor grey =
311 { 1, CGGI_CopyImageFromCanvasToAlphaInfo };
312 static CGGI_GlyphInfoDescriptor rgb =
313 { 3, CGGI_CopyImageFromCanvasToRGBInfo };
314
315 static inline CGGI_RenderingMode
316 CGGI_GetRenderingMode(const AWTStrike *strike)
317 {
318 CGGI_RenderingMode mode;
319 mode.cgFontMode = strike-fStyle;
320
321 switch (strike-fAAStyle) {
322 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_OFF:
323 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_ON:
324 mode.glyphDescriptor = grey;
325 break;
326 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HRGB:
327 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HBGR:
328 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VRGB:
329 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VBGR:
330 mode.glyphDescriptor = rgb;
331 break;
332 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
333 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
334 default:
335 // TODO: generate an error?
336 break;
337 }
.. If we get to default does this mean aliased rendering ?
If so why would OFF go the grey path - seems it should go default
And GASP looks like there is no support to specify the intended
meaning there
Given that OS X text is unhinted I'd think ON is a better option here
even though most fonts would do OFF at typical screen sizes .. but
that's
because they are expecting hinted rendering. So I think you need to get
hinted glyphs to default this to aliased ..
If my understanding is correct, we never get TEXT_ANTIALIAS_GASP and
TEXT_ANTIALIAS_DEFAULT here, because these hints must be already evaluated
and translated to either TEXT_ANTIALIAS_OFF, or TEXT_ANTIALIAS_ON.
It should be done in SunGraphisc2D.checkFontInfo(), lines 699 - 775.
At this point we have no enough info to evaluate these hints properly,
and a best solution is probably to raise an error.
Thanks,
Andrew
-phil.
On 10/10/14 2:13 PM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 10/11/2014 12:49 AM, Phil Race wrote:
On 10/10/14 11:05 AM, Andrew Brygin wrote:
Hello Phil,
changes in SunGraphics2D and SurfaceData were made in order to
implement an approach 'LCD instead of greyscale AA if possible'.
Without this part of change, we get results according to the hints:
greyscale for TEXT_ANTIALIAS_ON, and subpixels for lcd hints:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.01/
So you are changing the meaning of application-specified ON across
platforms ?
That sounds wrong - even for Mac ...
now I do not: the fix revision 01 does not change the meaning of the
hints,
and just makes text rendering on macosx to behave in a similar manner as
on windows.
Please take a look at the webrev.01.
Thanks,
Andrew
I am not sure whether do we need to change the 'default'
behavior: at the moment it produces aliased text.
default has meant aliased in all the non-mac sun/oracle implementations
since JDK 1.2. We have talked about changing it to something
more modern but should not do it lightly ..
-phil.
Thanks,
Andrew
On 10/10/2014 8:54 PM, Phil Race wrote:
I don't have my head around all these changes but a lot of it seems to
imply we really weren't asking for LCDon Mac when we could/should.
The change in the shared SurfaceData.javais something I want to
ask about as you have commented out as follows ..
;
749
750 // TODO: we have to take into account aaHint on macosx
751 //case SunHints.INTVAL_TEXT_ANTIALIAS_ON:
752 //return aaTextRenderer;
...
that looks like the case where the application code has *explicitly*
specified greyscale (ON==greyscale) so I don't see why you need
to go check the fontinfo in this case ?
-phil.
On 10/10/2014 07:34 AM, Andrew Brygin wrote:
Hello Denis,
could you please take a look at a preliminary version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/
This fix promotes the text antialiasing from grayscale to LCD if
destination surface data is able to render LCD, and provides
selection of an appropriate text pipeline for both cases.
It also separates production of gatyscale and LCD glyph images.
Thanks,
Andrew
On 10/9/2014
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
On 10/13/2014 05:41 AM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 10/13/2014 12:05 AM, Phil Race wrote:
373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
374 fontHints.put(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HBGR);
I am not sure why we have the graphics AA hint ON set here.
Its not truly a font hint even though if its set it implcitly triggers font AA
to be on too.
If you remove that first line do you notice any problems with Swing apps ?
I failed to spot any difference in the SwingSet2 demo after removal
the line 373.
Hmm .. Sergey seemed to suggest it was needed.
I was concerned that it might subvert the text rendering hint
as it used to cause us to do everything via the graphics AA loops.
So I guess I am not sure what the impact of removing it will be
You probably should check if it changes Metal Nimbus rendering
in SwingSet as it looks to be read by those but I don't see anywhere
Aqua is reading these hints which is puzzling as you'd think that's
where they were wanted.
The logic in the following code looks odd to me ..
310 static CGGI_GlyphInfoDescriptor grey =
311 { 1, CGGI_CopyImageFromCanvasToAlphaInfo };
312 static CGGI_GlyphInfoDescriptor rgb =
313 { 3, CGGI_CopyImageFromCanvasToRGBInfo };
314
315 static inline CGGI_RenderingMode
316 CGGI_GetRenderingMode(const AWTStrike *strike)
317 {
318 CGGI_RenderingMode mode;
319 mode.cgFontMode = strike-fStyle;
320
321 switch (strike-fAAStyle) {
322 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_OFF:
323 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_ON:
324 mode.glyphDescriptor = grey;
325 break;
326 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HRGB:
327 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HBGR:
328 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VRGB:
329 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VBGR:
330 mode.glyphDescriptor = rgb;
331 break;
332 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
333 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
334 default:
335 // TODO: generate an error?
336 break;
337 }
.. If we get to default does this mean aliased rendering ?
If so why would OFF go the grey path - seems it should go default
And GASP looks like there is no support to specify the intended
meaning there
Given that OS X text is unhinted I'd think ON is a better option here
even though most fonts would do OFF at typical screen sizes .. but
that's
because they are expecting hinted rendering. So I think you need to get
hinted glyphs to default this to aliased ..
If my understanding is correct, we never get TEXT_ANTIALIAS_GASP and
TEXT_ANTIALIAS_DEFAULT here, because these hints must be already evaluated
and translated to either TEXT_ANTIALIAS_OFF, or TEXT_ANTIALIAS_ON.
It should be done in SunGraphisc2D.checkFontInfo(), lines 699 - 775.
this is probably right so its OK ..
-phil.
At this point we have no enough info to evaluate these hints properly,
and a best solution is probably to raise an error.
Thanks,
Andrew
-phil.
On 10/10/14 2:13 PM, Andrew Brygin wrote:
Hello Phil,
please see my comments inline.
On 10/11/2014 12:49 AM, Phil Race wrote:
On 10/10/14 11:05 AM, Andrew Brygin wrote:
Hello Phil,
changes in SunGraphics2D and SurfaceData were made in order to
implement an approach 'LCD instead of greyscale AA if possible'.
Without this part of change, we get results according to the hints:
greyscale for TEXT_ANTIALIAS_ON, and subpixels for lcd hints:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.01/
So you are changing the meaning of application-specified ON
across platforms ?
That sounds wrong - even for Mac ...
now I do not: the fix revision 01 does not change the meaning of the
hints,
and just makes text rendering on macosx to behave in a similar
manner as
on windows.
Please take a look at the webrev.01.
Thanks,
Andrew
I am not sure whether do we need to change the 'default'
behavior: at the moment it produces aliased text.
default has meant aliased in all the non-mac sun/oracle implementations
since JDK 1.2. We have talked about changing it to something
more modern but should not do it lightly ..
-phil.
Thanks,
Andrew
On 10/10/2014 8:54 PM, Phil Race wrote:
I don't have my head around all these changes but a lot of it
seems to
imply we really weren't asking for LCDon Mac when we could/should.
The change in the shared SurfaceData.javais something I want to
ask about as you have commented out as follows ..
;
749
750 // TODO: we have to take into account aaHint on macosx
751 //case SunHints.INTVAL_TEXT_ANTIALIAS_ON:
752 //return aaTextRenderer;
...
that looks like the case where the application code has *explicitly*
specified
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello Denis,
could you please take a look at a preliminary version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/
This fix promotes the text antialiasing from grayscale to LCD if
destination surface data is able to render LCD, and provides
selection of an appropriate text pipeline for both cases.
It also separates production of gatyscale and LCD glyph images.
Thanks,
Andrew
On 10/9/2014 4:13 PM, Denis Fokin wrote:
Hi Andrew,
I am happy about you participation in this work!
Looks like, I have missed this letter, while being sick. Sorry about this.
I signed OCA, but I have not gotten access to cr.openjdk.java.net
http://cr.openjdk.java.net yet. This is the reason why I have not
updated the webrev.
I think that an API that is consistent with other platforms is a great
solution. It just requires more efforts and multi-platform testing. On
the other hand, a property could be a safe start.
As for the offscreen rendering, I have some kind of a workaround with
the next approach.
In BufImgSurfaceData.getRenderLoops() I always return
super.getRenderLoops(sg2d), and never solid loops.
In case if “useQuartz flag is specified, I return only
lcdTextRenderer from SurfaceData.getTextPipe()
Of course it is a brute force approach, but it allows producing a
legible text in case of offscreen rendering.
Thank you,
Denis.
On 29 Sep 2014, at 19:30, Andrew Brygin andrew.bry...@oracle.com
mailto:andrew.bry...@oracle.com wrote:
Hello Denis,
I am not sure whether we should use 'apple.awt.graphics.UseQuartz'
property.
Probably we have to change the text antialiasing defaults for macosx
instead.
I am working on the issue with software loops. I will update the thread
with my findings.
Thanks,
Andrew
On 9/3/2014 3:32 PM, Denis Fokin wrote:
Hi Sergey and 2d team,
I have rewritten the fix. It works fine for text rendered on window
using OpenGL.
http://web-dot.ru/openjdk/8023794/webrev.00/index.html
It is incomplete though. It does not work for rendering in a
buffered image.
Additionally, I have not tested the code on other platforms except
MacOS X.
To enable the antialiasing you should pass
-Dapple.awt.graphics.UseQuartz=true
to java.
The current issue now is the glyph info bytes that are passed from
CGGlyphImage to AATextRenderer.
To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing on
the macros a set of functions is generated for the next loops.
sun/java2d/loops/ByteGray.c
sun/java2d/loops/ByteIndexed.c
sun/java2d/loops/FourByteAbgr.c
sun/java2d/loops/FourByteAbgrPre.c
sun/java2d/loops/Index12Gray.c
sun/java2d/loops/Index8Gray.c
sun/java2d/loops/IntArgb.c
sun/java2d/loops/IntArgbBm.c
sun/java2d/loops/IntArgbPre.c
sun/java2d/loops/IntBgr.c
sun/java2d/loops/IntRgb.c
sun/java2d/loops/IntRgbx.c
sun/java2d/loops/LoopMacros.h
sun/java2d/loops/ThreeByteBgr.c
sun/java2d/loops/Ushort555Rgb.c
sun/java2d/loops/Ushort555Rgbx.c
sun/java2d/loops/Ushort565Rgb.c
sun/java2d/loops/UshortGray.c
sun/java2d/loops/UshortIndexed.c
For instance, C preprocessor generates the next code for IntRgb.c
voidIntRgbDrawGlyphListLCD(/*…*/){
jint glyphCounter, bpp;
jint scan = pRasInfo-scanStride;
IntRgbDataType *pPix;
fprintf(__stderrp, NAME_SOLID_DRAWGLYPHLISTLC\n);
jint srcA;
jint srcR , srcG, srcB
do {
(srcB) = (argbcolor) 0xff;
(srcG) = ((argbcolor) 8) 0xff;
(srcR) = ((argbcolor) 16) 0xff;
(srcA) = ((argbcolor) 24) 0xff;
} while (0);;
// and so on…
Looks like rgb loop expects to see 4 8-bit color channels per pixel.
For now, I do not understand which contract should be honoured to
meet DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I
place bytes in GlyphInfo.
May be it should be set somewhere in Java code.
Could anyone share this knowledge with me?
Thank you,
Denis.
On 09 Jul 2014, at 19:22, Sergey Bylokhov
sergey.bylok...@oracle.com mailto:sergey.bylok...@oracle.com wrote:
Hello, Denis.
Thanks for this research!
On 09.07.2014 15:13, Denis Fokin wrote:
The current version consist of three parts.
1. We are rendering glyphs in offscreen images using Quartz
functions. This does not work without kCGBitmapByteOrder32Host mask.
I assume LCD hint does not work? this looks good.
2. We assume that subpixel antialiasing should not be used on a
non-opaque surface. As I understand the vImage in
CGLVolatileSurfaceManager is not related directly to our window.
For a start, I have hardcoded Transparency.OPAQUE, but it requires
much better understanding of the architecture to make a more
proper solution.
It is related to the CGLOffScreenSurfaceData, which is used as a
surface for VolatileImages. I check this code and looks like we
ignore type of the ColorModel and create a transparent native
texture anyway.
3. When I started using CGGI_CopyImageFromCanvasToRGBInfo as a
rendering mode, I had found that the little endian mode should be
undefined. Again, it might be an improper way to do this.
It seems
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
I don't have my head around all these changes but a lot of it seems to
imply we really weren't asking for LCDon Mac when we could/should.
The change in the shared SurfaceData.javais something I want to
ask about as you have commented out as follows ..
;
749
750 // TODO: we have to take into account aaHint on macosx
751 //case SunHints.INTVAL_TEXT_ANTIALIAS_ON:
752 //return aaTextRenderer;
...
that looks like the case where the application code has *explicitly*
specified greyscale (ON==greyscale) so I don't see why you need
to go check the fontinfo in this case ?
-phil.
On 10/10/2014 07:34 AM, Andrew Brygin wrote:
Hello Denis,
could you please take a look at a preliminary version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/
This fix promotes the text antialiasing from grayscale to LCD if
destination surface data is able to render LCD, and provides
selection of an appropriate text pipeline for both cases.
It also separates production of gatyscale and LCD glyph images.
Thanks,
Andrew
On 10/9/2014 4:13 PM, Denis Fokin wrote:
Hi Andrew,
I am happy about you participation in this work!
Looks like, I have missed this letter, while being sick. Sorry about
this.
I signed OCA, but I have not gotten access to cr.openjdk.java.net
http://cr.openjdk.java.net yet. This is the reason why I have not
updated the webrev.
I think that an API that is consistent with other platforms is a
great solution. It just requires more efforts and multi-platform
testing. On the other hand, a property could be a safe start.
As for the offscreen rendering, I have some kind of a workaround with
the next approach.
In BufImgSurfaceData.getRenderLoops() I always return
super.getRenderLoops(sg2d), and never solid loops.
In case if “useQuartz flag is specified, I return only
lcdTextRenderer from SurfaceData.getTextPipe()
Of course it is a brute force approach, but it allows producing a
legible text in case of offscreen rendering.
Thank you,
Denis.
On 29 Sep 2014, at 19:30, Andrew Brygin andrew.bry...@oracle.com
mailto:andrew.bry...@oracle.com wrote:
Hello Denis,
I am not sure whether we should use 'apple.awt.graphics.UseQuartz'
property.
Probably we have to change the text antialiasing defaults for
macosx instead.
I am working on the issue with software loops. I will update the thread
with my findings.
Thanks,
Andrew
On 9/3/2014 3:32 PM, Denis Fokin wrote:
Hi Sergey and 2d team,
I have rewritten the fix. It works fine for text rendered on window
using OpenGL.
http://web-dot.ru/openjdk/8023794/webrev.00/index.html
It is incomplete though. It does not work for rendering in a
buffered image.
Additionally, I have not tested the code on other platforms except
MacOS X.
To enable the antialiasing you should pass
-Dapple.awt.graphics.UseQuartz=true
to java.
The current issue now is the glyph info bytes that are passed from
CGGlyphImage to AATextRenderer.
To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing on
the macros a set of functions is generated for the next loops.
sun/java2d/loops/ByteGray.c
sun/java2d/loops/ByteIndexed.c
sun/java2d/loops/FourByteAbgr.c
sun/java2d/loops/FourByteAbgrPre.c
sun/java2d/loops/Index12Gray.c
sun/java2d/loops/Index8Gray.c
sun/java2d/loops/IntArgb.c
sun/java2d/loops/IntArgbBm.c
sun/java2d/loops/IntArgbPre.c
sun/java2d/loops/IntBgr.c
sun/java2d/loops/IntRgb.c
sun/java2d/loops/IntRgbx.c
sun/java2d/loops/LoopMacros.h
sun/java2d/loops/ThreeByteBgr.c
sun/java2d/loops/Ushort555Rgb.c
sun/java2d/loops/Ushort555Rgbx.c
sun/java2d/loops/Ushort565Rgb.c
sun/java2d/loops/UshortGray.c
sun/java2d/loops/UshortIndexed.c
For instance, C preprocessor generates the next code for IntRgb.c
voidIntRgbDrawGlyphListLCD(/*…*/){
jint glyphCounter, bpp;
jint scan = pRasInfo-scanStride;
IntRgbDataType *pPix;
fprintf(__stderrp, NAME_SOLID_DRAWGLYPHLISTLC\n);
jint srcA;
jint srcR , srcG, srcB
do {
(srcB) = (argbcolor) 0xff;
(srcG) = ((argbcolor) 8) 0xff;
(srcR) = ((argbcolor) 16) 0xff;
(srcA) = ((argbcolor) 24) 0xff;
} while (0);;
// and so on…
Looks like rgb loop expects to see 4 8-bit color channels per pixel.
For now, I do not understand which contract should be honoured to
meet DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I
place bytes in GlyphInfo.
May be it should be set somewhere in Java code.
Could anyone share this knowledge with me?
Thank you,
Denis.
On 09 Jul 2014, at 19:22, Sergey Bylokhov
sergey.bylok...@oracle.com mailto:sergey.bylok...@oracle.com wrote:
Hello, Denis.
Thanks for this research!
On 09.07.2014 15:13, Denis Fokin wrote:
The current version consist of three parts.
1. We are rendering glyphs in offscreen images using Quartz
functions. This does not work without kCGBitmapByteOrder32Host mask.
I assume LCD hint does not work? this looks good.
2. We assume that subpixel antialiasing should not be used on a
non-opaque
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hi Phill,
I think this was commented out because the implementation did not work without
kCGBitmapByteOrder32Host mask.
Thank you,
Denis.
On 10 Oct 2014, at 20:54, Phil Race philip.r...@oracle.com wrote:
I don't have my head around all these changes but a lot of it seems to
imply we really weren't asking for LCDon Mac when we could/should.
The change in the shared SurfaceData.javais something I want to
ask about as you have commented out as follows ..
;
749
750 // TODO: we have to take into account aaHint on macosx
751 //case SunHints.INTVAL_TEXT_ANTIALIAS_ON:
752 //return aaTextRenderer;
...
that looks like the case where the application code has *explicitly*
specified greyscale (ON==greyscale) so I don't see why you need
to go check the fontinfo in this case ?
-phil.
On 10/10/2014 07:34 AM, Andrew Brygin wrote:
Hello Denis,
could you please take a look at a preliminary version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/
This fix promotes the text antialiasing from grayscale to LCD if
destination surface data is able to render LCD, and provides
selection of an appropriate text pipeline for both cases.
It also separates production of gatyscale and LCD glyph images.
Thanks,
Andrew
On 10/9/2014 4:13 PM, Denis Fokin wrote:
Hi Andrew,
I am happy about you participation in this work!
Looks like, I have missed this letter, while being sick. Sorry about this.
I signed OCA, but I have not gotten access to cr.openjdk.java.net yet. This
is the reason why I have not updated the webrev.
I think that an API that is consistent with other platforms is a great
solution. It just requires more efforts and multi-platform testing. On the
other hand, a property could be a safe start.
As for the offscreen rendering, I have some kind of a workaround with the
next approach.
In BufImgSurfaceData.getRenderLoops() I always return
super.getRenderLoops(sg2d), and never solid loops.
In case if “useQuartz flag is specified, I return only lcdTextRenderer
from SurfaceData.getTextPipe()
Of course it is a brute force approach, but it allows producing a legible
text in case of offscreen rendering.
Thank you,
Denis.
On 29 Sep 2014, at 19:30, Andrew Brygin andrew.bry...@oracle.com wrote:
Hello Denis,
I am not sure whether we should use 'apple.awt.graphics.UseQuartz'
property.
Probably we have to change the text antialiasing defaults for macosx
instead.
I am working on the issue with software loops. I will update the thread
with my findings.
Thanks,
Andrew
On 9/3/2014 3:32 PM, Denis Fokin wrote:
Hi Sergey and 2d team,
I have rewritten the fix. It works fine for text rendered on window using
OpenGL.
http://web-dot.ru/openjdk/8023794/webrev.00/index.html
It is incomplete though. It does not work for rendering in a buffered
image.
Additionally, I have not tested the code on other platforms except MacOS
X.
To enable the antialiasing you should pass
-Dapple.awt.graphics.UseQuartz=true
to java.
The current issue now is the glyph info bytes that are passed from
CGGlyphImage to AATextRenderer.
To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing on the
macros a set of functions is generated for the next loops.
sun/java2d/loops/ByteGray.c
sun/java2d/loops/ByteIndexed.c
sun/java2d/loops/FourByteAbgr.c
sun/java2d/loops/FourByteAbgrPre.c
sun/java2d/loops/Index12Gray.c
sun/java2d/loops/Index8Gray.c
sun/java2d/loops/IntArgb.c
sun/java2d/loops/IntArgbBm.c
sun/java2d/loops/IntArgbPre.c
sun/java2d/loops/IntBgr.c
sun/java2d/loops/IntRgb.c
sun/java2d/loops/IntRgbx.c
sun/java2d/loops/LoopMacros.h
sun/java2d/loops/ThreeByteBgr.c
sun/java2d/loops/Ushort555Rgb.c
sun/java2d/loops/Ushort555Rgbx.c
sun/java2d/loops/Ushort565Rgb.c
sun/java2d/loops/UshortGray.c
sun/java2d/loops/UshortIndexed.c
For instance, C preprocessor generates the next code for IntRgb.c
void IntRgbDrawGlyphListLCD(/*…*/){
jint glyphCounter, bpp;
jint scan = pRasInfo-scanStride;
IntRgbDataType *pPix;
fprintf(__stderrp, NAME_SOLID_DRAWGLYPHLISTLC\n);
jint srcA;
jint srcR , srcG, srcB
do {
(srcB) = (argbcolor) 0xff;
(srcG) = ((argbcolor) 8) 0xff;
(srcR) = ((argbcolor) 16) 0xff;
(srcA) = ((argbcolor) 24) 0xff;
} while (0);;
// and so on…
Looks like rgb loop expects to see 4 8-bit color channels per pixel.
For now, I do not understand which contract should be honoured to meet
DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I place bytes
in GlyphInfo.
May be it should be set somewhere in Java code.
Could anyone share this knowledge with me?
Thank you,
Denis.
On 09 Jul 2014, at 19:22, Sergey Bylokhov sergey.bylok...@oracle.com
wrote:
Hello, Denis.
Thanks for this research!
On 09.07.2014 15:13, Denis Fokin wrote:
The current version
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello Phil,
changes in SunGraphics2D and SurfaceData were made in order to
implement an approach 'LCD instead of greyscale AA if possible'.
Without this part of change, we get results according to the hints:
greyscale for TEXT_ANTIALIAS_ON, and subpixels for lcd hints:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.01/
I am not sure whether do we need to change the 'default'
behavior: at the moment it produces aliased text.
Thanks,
Andrew
On 10/10/2014 8:54 PM, Phil Race wrote:
I don't have my head around all these changes but a lot of it seems to
imply we really weren't asking for LCDon Mac when we could/should.
The change in the shared SurfaceData.javais something I want to
ask about as you have commented out as follows ..
;
749
750 // TODO: we have to take into account aaHint on macosx
751 //case SunHints.INTVAL_TEXT_ANTIALIAS_ON:
752 //return aaTextRenderer;
...
that looks like the case where the application code has *explicitly*
specified greyscale (ON==greyscale) so I don't see why you need
to go check the fontinfo in this case ?
-phil.
On 10/10/2014 07:34 AM, Andrew Brygin wrote:
Hello Denis,
could you please take a look at a preliminary version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/
This fix promotes the text antialiasing from grayscale to LCD if
destination surface data is able to render LCD, and provides
selection of an appropriate text pipeline for both cases.
It also separates production of gatyscale and LCD glyph images.
Thanks,
Andrew
On 10/9/2014 4:13 PM, Denis Fokin wrote:
Hi Andrew,
I am happy about you participation in this work!
Looks like, I have missed this letter, while being sick. Sorry about
this.
I signed OCA, but I have not gotten access to cr.openjdk.java.net
http://cr.openjdk.java.net yet. This is the reason why I have not
updated the webrev.
I think that an API that is consistent with other platforms is a
great solution. It just requires more efforts and multi-platform
testing. On the other hand, a property could be a safe start.
As for the offscreen rendering, I have some kind of a workaround
with the next approach.
In BufImgSurfaceData.getRenderLoops() I always return
super.getRenderLoops(sg2d), and never solid loops.
In case if “useQuartz flag is specified, I return only
lcdTextRenderer from SurfaceData.getTextPipe()
Of course it is a brute force approach, but it allows producing a
legible text in case of offscreen rendering.
Thank you,
Denis.
On 29 Sep 2014, at 19:30, Andrew Brygin andrew.bry...@oracle.com
mailto:andrew.bry...@oracle.com wrote:
Hello Denis,
I am not sure whether we should use 'apple.awt.graphics.UseQuartz'
property.
Probably we have to change the text antialiasing defaults for
macosx instead.
I am working on the issue with software loops. I will update the
thread
with my findings.
Thanks,
Andrew
On 9/3/2014 3:32 PM, Denis Fokin wrote:
Hi Sergey and 2d team,
I have rewritten the fix. It works fine for text rendered on
window using OpenGL.
http://web-dot.ru/openjdk/8023794/webrev.00/index.html
It is incomplete though. It does not work for rendering in a
buffered image.
Additionally, I have not tested the code on other platforms except
MacOS X.
To enable the antialiasing you should pass
-Dapple.awt.graphics.UseQuartz=true
to java.
The current issue now is the glyph info bytes that are passed from
CGGlyphImage to AATextRenderer.
To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing
on the macros a set of functions is generated for the next loops.
sun/java2d/loops/ByteGray.c
sun/java2d/loops/ByteIndexed.c
sun/java2d/loops/FourByteAbgr.c
sun/java2d/loops/FourByteAbgrPre.c
sun/java2d/loops/Index12Gray.c
sun/java2d/loops/Index8Gray.c
sun/java2d/loops/IntArgb.c
sun/java2d/loops/IntArgbBm.c
sun/java2d/loops/IntArgbPre.c
sun/java2d/loops/IntBgr.c
sun/java2d/loops/IntRgb.c
sun/java2d/loops/IntRgbx.c
sun/java2d/loops/LoopMacros.h
sun/java2d/loops/ThreeByteBgr.c
sun/java2d/loops/Ushort555Rgb.c
sun/java2d/loops/Ushort555Rgbx.c
sun/java2d/loops/Ushort565Rgb.c
sun/java2d/loops/UshortGray.c
sun/java2d/loops/UshortIndexed.c
For instance, C preprocessor generates the next code for IntRgb.c
voidIntRgbDrawGlyphListLCD(/*…*/){
jint glyphCounter, bpp;
jint scan = pRasInfo-scanStride;
IntRgbDataType *pPix;
fprintf(__stderrp, NAME_SOLID_DRAWGLYPHLISTLC\n);
jint srcA;
jint srcR , srcG, srcB
do {
(srcB) = (argbcolor) 0xff;
(srcG) = ((argbcolor) 8) 0xff;
(srcR) = ((argbcolor) 16) 0xff;
(srcA) = ((argbcolor) 24) 0xff;
} while (0);;
// and so on…
Looks like rgb loop expects to see 4 8-bit color channels per pixel.
For now, I do not understand which contract should be honoured to
meet DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I
place bytes in GlyphInfo.
May be it should be set somewhere in Java code.
Could anyone share this knowledge with me?
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
On 10/10/14 11:05 AM, Andrew Brygin wrote:
Hello Phil,
changes in SunGraphics2D and SurfaceData were made in order to
implement an approach 'LCD instead of greyscale AA if possible'.
Without this part of change, we get results according to the hints:
greyscale for TEXT_ANTIALIAS_ON, and subpixels for lcd hints:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.01/
So you are changing the meaning of application-specified ON across
platforms ?
That sounds wrong - even for Mac ...
I am not sure whether do we need to change the 'default'
behavior: at the moment it produces aliased text.
default has meant aliased in all the non-mac sun/oracle implementations
since JDK 1.2. We have talked about changing it to something
more modern but should not do it lightly ..
-phil.
Thanks,
Andrew
On 10/10/2014 8:54 PM, Phil Race wrote:
I don't have my head around all these changes but a lot of it seems to
imply we really weren't asking for LCDon Mac when we could/should.
The change in the shared SurfaceData.javais something I want to
ask about as you have commented out as follows ..
;
749
750 // TODO: we have to take into account aaHint on macosx
751 //case SunHints.INTVAL_TEXT_ANTIALIAS_ON:
752 //return aaTextRenderer;
...
that looks like the case where the application code has *explicitly*
specified greyscale (ON==greyscale) so I don't see why you need
to go check the fontinfo in this case ?
-phil.
On 10/10/2014 07:34 AM, Andrew Brygin wrote:
Hello Denis,
could you please take a look at a preliminary version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/
This fix promotes the text antialiasing from grayscale to LCD if
destination surface data is able to render LCD, and provides
selection of an appropriate text pipeline for both cases.
It also separates production of gatyscale and LCD glyph images.
Thanks,
Andrew
On 10/9/2014 4:13 PM, Denis Fokin wrote:
Hi Andrew,
I am happy about you participation in this work!
Looks like, I have missed this letter, while being sick. Sorry
about this.
I signed OCA, but I have not gotten access to cr.openjdk.java.net
http://cr.openjdk.java.net yet. This is the reason why I have not
updated the webrev.
I think that an API that is consistent with other platforms is a
great solution. It just requires more efforts and multi-platform
testing. On the other hand, a property could be a safe start.
As for the offscreen rendering, I have some kind of a workaround
with the next approach.
In BufImgSurfaceData.getRenderLoops() I always return
super.getRenderLoops(sg2d), and never solid loops.
In case if “useQuartz flag is specified, I return only
lcdTextRenderer from SurfaceData.getTextPipe()
Of course it is a brute force approach, but it allows producing a
legible text in case of offscreen rendering.
Thank you,
Denis.
On 29 Sep 2014, at 19:30, Andrew Brygin andrew.bry...@oracle.com
mailto:andrew.bry...@oracle.com wrote:
Hello Denis,
I am not sure whether we should use
'apple.awt.graphics.UseQuartz' property.
Probably we have to change the text antialiasing defaults for
macosx instead.
I am working on the issue with software loops. I will update the
thread
with my findings.
Thanks,
Andrew
On 9/3/2014 3:32 PM, Denis Fokin wrote:
Hi Sergey and 2d team,
I have rewritten the fix. It works fine for text rendered on
window using OpenGL.
http://web-dot.ru/openjdk/8023794/webrev.00/index.html
It is incomplete though. It does not work for rendering in a
buffered image.
Additionally, I have not tested the code on other platforms
except MacOS X.
To enable the antialiasing you should pass
-Dapple.awt.graphics.UseQuartz=true
to java.
The current issue now is the glyph info bytes that are passed
from CGGlyphImage to AATextRenderer.
To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing
on the macros a set of functions is generated for the next loops.
sun/java2d/loops/ByteGray.c
sun/java2d/loops/ByteIndexed.c
sun/java2d/loops/FourByteAbgr.c
sun/java2d/loops/FourByteAbgrPre.c
sun/java2d/loops/Index12Gray.c
sun/java2d/loops/Index8Gray.c
sun/java2d/loops/IntArgb.c
sun/java2d/loops/IntArgbBm.c
sun/java2d/loops/IntArgbPre.c
sun/java2d/loops/IntBgr.c
sun/java2d/loops/IntRgb.c
sun/java2d/loops/IntRgbx.c
sun/java2d/loops/LoopMacros.h
sun/java2d/loops/ThreeByteBgr.c
sun/java2d/loops/Ushort555Rgb.c
sun/java2d/loops/Ushort555Rgbx.c
sun/java2d/loops/Ushort565Rgb.c
sun/java2d/loops/UshortGray.c
sun/java2d/loops/UshortIndexed.c
For instance, C preprocessor generates the next code for IntRgb.c
voidIntRgbDrawGlyphListLCD(/*…*/){
jint glyphCounter, bpp;
jint scan = pRasInfo-scanStride;
IntRgbDataType *pPix;
fprintf(__stderrp, NAME_SOLID_DRAWGLYPHLISTLC\n);
jint srcA;
jint srcR , srcG, srcB
do {
(srcB) = (argbcolor) 0xff;
(srcG) = ((argbcolor) 8) 0xff;
(srcR) = ((argbcolor) 16) 0xff;
(srcA) = ((argbcolor) 24) 0xff;
}
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello Phil,
please see my comments inline.
On 10/11/2014 12:49 AM, Phil Race wrote:
On 10/10/14 11:05 AM, Andrew Brygin wrote:
Hello Phil,
changes in SunGraphics2D and SurfaceData were made in order to
implement an approach 'LCD instead of greyscale AA if possible'.
Without this part of change, we get results according to the hints:
greyscale for TEXT_ANTIALIAS_ON, and subpixels for lcd hints:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.01/
So you are changing the meaning of application-specified ON across
platforms ?
That sounds wrong - even for Mac ...
now I do not: the fix revision 01 does not change the meaning of the hints,
and just makes text rendering on macosx to behave in a similar manner as
on windows.
Please take a look at the webrev.01.
Thanks,
Andrew
I am not sure whether do we need to change the 'default'
behavior: at the moment it produces aliased text.
default has meant aliased in all the non-mac sun/oracle implementations
since JDK 1.2. We have talked about changing it to something
more modern but should not do it lightly ..
-phil.
Thanks,
Andrew
On 10/10/2014 8:54 PM, Phil Race wrote:
I don't have my head around all these changes but a lot of it seems to
imply we really weren't asking for LCDon Mac when we could/should.
The change in the shared SurfaceData.javais something I want to
ask about as you have commented out as follows ..
;
749
750 // TODO: we have to take into account aaHint on macosx
751 //case SunHints.INTVAL_TEXT_ANTIALIAS_ON:
752 //return aaTextRenderer;
...
that looks like the case where the application code has *explicitly*
specified greyscale (ON==greyscale) so I don't see why you need
to go check the fontinfo in this case ?
-phil.
On 10/10/2014 07:34 AM, Andrew Brygin wrote:
Hello Denis,
could you please take a look at a preliminary version of the fix?
http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/
This fix promotes the text antialiasing from grayscale to LCD if
destination surface data is able to render LCD, and provides
selection of an appropriate text pipeline for both cases.
It also separates production of gatyscale and LCD glyph images.
Thanks,
Andrew
On 10/9/2014 4:13 PM, Denis Fokin wrote:
Hi Andrew,
I am happy about you participation in this work!
Looks like, I have missed this letter, while being sick. Sorry
about this.
I signed OCA, but I have not gotten access to cr.openjdk.java.net
http://cr.openjdk.java.net yet. This is the reason why I have
not updated the webrev.
I think that an API that is consistent with other platforms is a
great solution. It just requires more efforts and multi-platform
testing. On the other hand, a property could be a safe start.
As for the offscreen rendering, I have some kind of a workaround
with the next approach.
In BufImgSurfaceData.getRenderLoops() I always return
super.getRenderLoops(sg2d), and never solid loops.
In case if “useQuartz flag is specified, I return only
lcdTextRenderer from SurfaceData.getTextPipe()
Of course it is a brute force approach, but it allows producing a
legible text in case of offscreen rendering.
Thank you,
Denis.
On 29 Sep 2014, at 19:30, Andrew Brygin andrew.bry...@oracle.com
mailto:andrew.bry...@oracle.com wrote:
Hello Denis,
I am not sure whether we should use
'apple.awt.graphics.UseQuartz' property.
Probably we have to change the text antialiasing defaults for
macosx instead.
I am working on the issue with software loops. I will update the
thread
with my findings.
Thanks,
Andrew
On 9/3/2014 3:32 PM, Denis Fokin wrote:
Hi Sergey and 2d team,
I have rewritten the fix. It works fine for text rendered on
window using OpenGL.
http://web-dot.ru/openjdk/8023794/webrev.00/index.html
It is incomplete though. It does not work for rendering in a
buffered image.
Additionally, I have not tested the code on other platforms
except MacOS X.
To enable the antialiasing you should pass
-Dapple.awt.graphics.UseQuartz=true
to java.
The current issue now is the glyph info bytes that are passed
from CGGlyphImage to AATextRenderer.
To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing
on the macros a set of functions is generated for the next loops.
sun/java2d/loops/ByteGray.c
sun/java2d/loops/ByteIndexed.c
sun/java2d/loops/FourByteAbgr.c
sun/java2d/loops/FourByteAbgrPre.c
sun/java2d/loops/Index12Gray.c
sun/java2d/loops/Index8Gray.c
sun/java2d/loops/IntArgb.c
sun/java2d/loops/IntArgbBm.c
sun/java2d/loops/IntArgbPre.c
sun/java2d/loops/IntBgr.c
sun/java2d/loops/IntRgb.c
sun/java2d/loops/IntRgbx.c
sun/java2d/loops/LoopMacros.h
sun/java2d/loops/ThreeByteBgr.c
sun/java2d/loops/Ushort555Rgb.c
sun/java2d/loops/Ushort555Rgbx.c
sun/java2d/loops/Ushort565Rgb.c
sun/java2d/loops/UshortGray.c
sun/java2d/loops/UshortIndexed.c
For instance, C preprocessor generates the next code for IntRgb.c
voidIntRgbDrawGlyphListLCD(/*…*/){
jint glyphCounter, bpp;
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hi Andrew,
I am happy about you participation in this work!
Looks like, I have missed this letter, while being sick. Sorry about this.
I signed OCA, but I have not gotten access to cr.openjdk.java.net yet. This is
the reason why I have not updated the webrev.
I think that an API that is consistent with other platforms is a great
solution. It just requires more efforts and multi-platform testing. On the
other hand, a property could be a safe start.
As for the offscreen rendering, I have some kind of a workaround with the next
approach.
In BufImgSurfaceData.getRenderLoops() I always return
super.getRenderLoops(sg2d), and never solid loops.
In case if “useQuartz flag is specified, I return only lcdTextRenderer from
SurfaceData.getTextPipe()
Of course it is a brute force approach, but it allows producing a legible text
in case of offscreen rendering.
Thank you,
Denis.
On 29 Sep 2014, at 19:30, Andrew Brygin andrew.bry...@oracle.com wrote:
Hello Denis,
I am not sure whether we should use 'apple.awt.graphics.UseQuartz' property.
Probably we have to change the text antialiasing defaults for macosx instead.
I am working on the issue with software loops. I will update the thread
with my findings.
Thanks,
Andrew
On 9/3/2014 3:32 PM, Denis Fokin wrote:
Hi Sergey and 2d team,
I have rewritten the fix. It works fine for text rendered on window using
OpenGL.
http://web-dot.ru/openjdk/8023794/webrev.00/index.html
It is incomplete though. It does not work for rendering in a buffered image.
Additionally, I have not tested the code on other platforms except MacOS X.
To enable the antialiasing you should pass
-Dapple.awt.graphics.UseQuartz=true
to java.
The current issue now is the glyph info bytes that are passed from
CGGlyphImage to AATextRenderer.
To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing on the
macros a set of functions is generated for the next loops.
sun/java2d/loops/ByteGray.c
sun/java2d/loops/ByteIndexed.c
sun/java2d/loops/FourByteAbgr.c
sun/java2d/loops/FourByteAbgrPre.c
sun/java2d/loops/Index12Gray.c
sun/java2d/loops/Index8Gray.c
sun/java2d/loops/IntArgb.c
sun/java2d/loops/IntArgbBm.c
sun/java2d/loops/IntArgbPre.c
sun/java2d/loops/IntBgr.c
sun/java2d/loops/IntRgb.c
sun/java2d/loops/IntRgbx.c
sun/java2d/loops/LoopMacros.h
sun/java2d/loops/ThreeByteBgr.c
sun/java2d/loops/Ushort555Rgb.c
sun/java2d/loops/Ushort555Rgbx.c
sun/java2d/loops/Ushort565Rgb.c
sun/java2d/loops/UshortGray.c
sun/java2d/loops/UshortIndexed.c
For instance, C preprocessor generates the next code for IntRgb.c
void IntRgbDrawGlyphListLCD(/*…*/){
jint glyphCounter, bpp;
jint scan = pRasInfo-scanStride;
IntRgbDataType *pPix;
fprintf(__stderrp, NAME_SOLID_DRAWGLYPHLISTLC\n);
jint srcA;
jint srcR , srcG, srcB
do {
(srcB) = (argbcolor) 0xff;
(srcG) = ((argbcolor) 8) 0xff;
(srcR) = ((argbcolor) 16) 0xff;
(srcA) = ((argbcolor) 24) 0xff;
} while (0);;
// and so on…
Looks like rgb loop expects to see 4 8-bit color channels per pixel.
For now, I do not understand which contract should be honoured to meet
DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I place bytes in
GlyphInfo.
May be it should be set somewhere in Java code.
Could anyone share this knowledge with me?
Thank you,
Denis.
On 09 Jul 2014, at 19:22, Sergey Bylokhov sergey.bylok...@oracle.com wrote:
Hello, Denis.
Thanks for this research!
On 09.07.2014 15:13, Denis Fokin wrote:
The current version consist of three parts.
1. We are rendering glyphs in offscreen images using Quartz functions.
This does not work without kCGBitmapByteOrder32Host mask.
I assume LCD hint does not work? this looks good.
2. We assume that subpixel antialiasing should not be used on a
non-opaque surface. As I understand the vImage in
CGLVolatileSurfaceManager is not related directly to our window. For a
start, I have hardcoded Transparency.OPAQUE, but it requires much better
understanding of the architecture to make a more proper solution.
It is related to the CGLOffScreenSurfaceData, which is used as a surface
for VolatileImages. I check this code and looks like we ignore type of the
ColorModel and create a transparent native texture anyway.
3. When I started using CGGI_CopyImageFromCanvasToRGBInfo as a rendering
mode, I had found that the little endian mode should be undefined. Again,
it might be an improper way to do this.
It seems __LITTLE_ENDIAN__usage in this file should be checked.
Thank you,
Denis.
diff -r f87c5be90e01
src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java
---
a/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaFri
Jun 20 10:15:30 2014 -0700
+++
b/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaWed
Jul 09 14:50:09 2014 +0400
@@ -108,7 +108,7 @@
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello Denis,
I am not sure whether we should use 'apple.awt.graphics.UseQuartz'
property.
Probably we have to change the text antialiasing defaults for macosx
instead.
I am working on the issue with software loops. I will update the thread
with my findings.
Thanks,
Andrew
On 9/3/2014 3:32 PM, Denis Fokin wrote:
Hi Sergey and 2d team,
I have rewritten the fix. It works fine for text rendered on window
using OpenGL.
http://web-dot.ru/openjdk/8023794/webrev.00/index.html
It is incomplete though. It does not work for rendering in a buffered
image.
Additionally, I have not tested the code on other platforms except
MacOS X.
To enable the antialiasing you should pass
-Dapple.awt.graphics.UseQuartz=true
to java.
The current issue now is the glyph info bytes that are passed from
CGGlyphImage to AATextRenderer.
To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing on
the macros a set of functions is generated for the next loops.
sun/java2d/loops/ByteGray.c
sun/java2d/loops/ByteIndexed.c
sun/java2d/loops/FourByteAbgr.c
sun/java2d/loops/FourByteAbgrPre.c
sun/java2d/loops/Index12Gray.c
sun/java2d/loops/Index8Gray.c
sun/java2d/loops/IntArgb.c
sun/java2d/loops/IntArgbBm.c
sun/java2d/loops/IntArgbPre.c
sun/java2d/loops/IntBgr.c
sun/java2d/loops/IntRgb.c
sun/java2d/loops/IntRgbx.c
sun/java2d/loops/LoopMacros.h
sun/java2d/loops/ThreeByteBgr.c
sun/java2d/loops/Ushort555Rgb.c
sun/java2d/loops/Ushort555Rgbx.c
sun/java2d/loops/Ushort565Rgb.c
sun/java2d/loops/UshortGray.c
sun/java2d/loops/UshortIndexed.c
For instance, C preprocessor generates the next code for IntRgb.c
voidIntRgbDrawGlyphListLCD(/*…*/){
jint glyphCounter, bpp;
jint scan = pRasInfo-scanStride;
IntRgbDataType *pPix;
fprintf(__stderrp, NAME_SOLID_DRAWGLYPHLISTLC\n);
jint srcA;
jint srcR , srcG, srcB
do {
(srcB) = (argbcolor) 0xff;
(srcG) = ((argbcolor) 8) 0xff;
(srcR) = ((argbcolor) 16) 0xff;
(srcA) = ((argbcolor) 24) 0xff;
} while (0);;
// and so on…
Looks like rgb loop expects to see 4 8-bit color channels per pixel.
For now, I do not understand which contract should be honoured to meet
DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I place
bytes in GlyphInfo.
May be it should be set somewhere in Java code.
Could anyone share this knowledge with me?
Thank you,
Denis.
On 09 Jul 2014, at 19:22, Sergey Bylokhov sergey.bylok...@oracle.com
mailto:sergey.bylok...@oracle.com wrote:
Hello, Denis.
Thanks for this research!
On 09.07.2014 15:13, Denis Fokin wrote:
The current version consist of three parts.
1. We are rendering glyphs in offscreen images using Quartz
functions. This does not work without kCGBitmapByteOrder32Host mask.
I assume LCD hint does not work? this looks good.
2. We assume that subpixel antialiasing should not be used on a
non-opaque surface. As I understand the vImage in
CGLVolatileSurfaceManager is not related directly to our window. For
a start, I have hardcoded Transparency.OPAQUE, but it requires much
better understanding of the architecture to make a more proper solution.
It is related to the CGLOffScreenSurfaceData, which is used as a
surface for VolatileImages. I check this code and looks like we
ignore type of the ColorModel and create a transparent native texture
anyway.
3. When I started using CGGI_CopyImageFromCanvasToRGBInfo as a
rendering mode, I had found that the little endian mode should be
undefined. Again, it might be an improper way to do this.
It seems __LITTLE_ENDIAN__usage in this file should be checked.
Thank you,
Denis.
diff -r f87c5be90e01
src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java
---
a/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaFri
Jun 20 10:15:30 2014 -0700
+++
b/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaWed
Jul 09 14:50:09 2014 +0400
@@ -108,7 +108,7 @@
} else {
CGLGraphicsConfig gc =
(CGLGraphicsConfig)vImg.getGraphicsConfig();
-ColorModel cm =
gc.getColorModel(vImg.getTransparency());
+ColorModel cm = gc.getColorModel(Transparency.OPAQUE);
int type = vImg.getForcedAccelSurfaceType();
// if acceleration type is forced (type !=
UNDEFINED) then
// use the forced type, otherwise choose one based
on caps
diff -r f87c5be90e01 src/macosx/native/sun/font/CGGlyphImages.m
--- a/src/macosx/native/sun/font/CGGlyphImages.mFri Jun 20 10:15:30
2014 -0700
+++ b/src/macosx/native/sun/font/.mWed Jul 09 14:50:09 2014 +0400
@@ -196,6 +196,8 @@
#pragma mark --- Font Rendering Mode Descriptors ---
+#undef __LITTLE_ENDIAN__
+
static inline void
CGGI_CopyARGBPixelToRGBPixel(const UInt32 p, UInt8 *dst)
{
@@ -366,7 +368,8 @@
canvas-context = CGBitmapContextCreate(canvas-image-data,
width, height, 8, bytesPerRow,
colorSpace,
- kCGImageAlphaPremultipliedFirst);
+ kCGImageAlphaPremultipliedFirst
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hi Sergey and 2d team,
I have rewritten the fix. It works fine for text rendered on window using
OpenGL.
http://web-dot.ru/openjdk/8023794/webrev.00/index.html
It is incomplete though. It does not work for rendering in a buffered image.
Additionally, I have not tested the code on other platforms except MacOS X.
To enable the antialiasing you should pass
-Dapple.awt.graphics.UseQuartz=true
to java.
The current issue now is the glyph info bytes that are passed from CGGlyphImage
to AATextRenderer.
To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing on the macros
a set of functions is generated for the next loops.
sun/java2d/loops/ByteGray.c
sun/java2d/loops/ByteIndexed.c
sun/java2d/loops/FourByteAbgr.c
sun/java2d/loops/FourByteAbgrPre.c
sun/java2d/loops/Index12Gray.c
sun/java2d/loops/Index8Gray.c
sun/java2d/loops/IntArgb.c
sun/java2d/loops/IntArgbBm.c
sun/java2d/loops/IntArgbPre.c
sun/java2d/loops/IntBgr.c
sun/java2d/loops/IntRgb.c
sun/java2d/loops/IntRgbx.c
sun/java2d/loops/LoopMacros.h
sun/java2d/loops/ThreeByteBgr.c
sun/java2d/loops/Ushort555Rgb.c
sun/java2d/loops/Ushort555Rgbx.c
sun/java2d/loops/Ushort565Rgb.c
sun/java2d/loops/UshortGray.c
sun/java2d/loops/UshortIndexed.c
For instance, C preprocessor generates the next code for IntRgb.c
voidIntRgbDrawGlyphListLCD(/*…*/){
jintglyphCounter, bpp;
jintscan = pRasInfo-scanStride;
IntRgbDataType *pPix;
fprintf(__stderrp, NAME_SOLID_DRAWGLYPHLISTLC\n);
jintsrcA;
jintsrcR , srcG, srcB
do {
(srcB) = (argbcolor) 0xff;
(srcG) = ((argbcolor) 8) 0xff;
(srcR) = ((argbcolor) 16) 0xff;
(srcA) = ((argbcolor) 24) 0xff;
} while (0);;
// and so on…
Looks like rgb loop expects to see 4 8-bit color channels per pixel.
For now, I do not understand which contract should be honoured to meet
DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I place bytes in
GlyphInfo.
May be it should be set somewhere in Java code.
Could anyone share this knowledge with me?
Thank you,
Denis.
On 09 Jul 2014, at 19:22, Sergey Bylokhov sergey.bylok...@oracle.com wrote:
Hello, Denis.
Thanks for this research!
On 09.07.2014 15:13, Denis Fokin wrote:
The current version consist of three parts.
1. We are rendering glyphs in offscreen images using Quartz functions. This
does not work without kCGBitmapByteOrder32Host mask.
I assume LCD hint does not work? this looks good.
2. We assume that subpixel antialiasing should not be used on a non-opaque
surface. As I understand the vImage in CGLVolatileSurfaceManager is not
related directly to our window. For a start, I have hardcoded
Transparency.OPAQUE, but it requires much better understanding of the
architecture to make a more proper solution.
It is related to the CGLOffScreenSurfaceData, which is used as a surface for
VolatileImages. I check this code and looks like we ignore type of the
ColorModel and create a transparent native texture anyway.
3. When I started using CGGI_CopyImageFromCanvasToRGBInfo as a rendering
mode, I had found that the little endian mode should be undefined. Again, it
might be an improper way to do this.
It seems __LITTLE_ENDIAN__usage in this file should be checked.
Thank you,
Denis.
diff -r f87c5be90e01
src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java
--- a/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaFri
Jun 20 10:15:30 2014 -0700
+++ b/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaWed
Jul 09 14:50:09 2014 +0400
@@ -108,7 +108,7 @@
} else {
CGLGraphicsConfig gc =
(CGLGraphicsConfig)vImg.getGraphicsConfig();
-ColorModel cm = gc.getColorModel(vImg.getTransparency());
+ColorModel cm = gc.getColorModel(Transparency.OPAQUE);
int type = vImg.getForcedAccelSurfaceType();
// if acceleration type is forced (type != UNDEFINED) then
// use the forced type, otherwise choose one based on caps
diff -r f87c5be90e01 src/macosx/native/sun/font/CGGlyphImages.m
--- a/src/macosx/native/sun/font/CGGlyphImages.mFri Jun 20 10:15:30 2014
-0700
+++ b/src/macosx/native/sun/font/.mWed Jul 09 14:50:09 2014 +0400
@@ -196,6 +196,8 @@
#pragma mark --- Font Rendering Mode Descriptors ---
+#undef __LITTLE_ENDIAN__
+
static inline void
CGGI_CopyARGBPixelToRGBPixel(const UInt32 p, UInt8 *dst)
{
@@ -366,7 +368,8 @@
canvas-context = CGBitmapContextCreate(canvas-image-data,
width, height, 8, bytesPerRow,
colorSpace,
- kCGImageAlphaPremultipliedFirst);
+ kCGImageAlphaPremultipliedFirst
+| kCGBitmapByteOrder32Host);
CGContextSetRGBFillColor(canvas-context, 0.0f, 0.0f, 0.0f, 1.0f);
CGContextSetFontSize(canvas-context, 1);
--
Best regards, Sergey.
Re: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
Hello, Denis.
Thanks for this research!
On 09.07.2014 15:13, Denis Fokin wrote:
The current version consist of three parts.
1. We are rendering glyphs in offscreen images using Quartz functions.
This does not work without kCGBitmapByteOrder32Host mask.
I assume LCD hint does not work? this looks good.
2. We assume that subpixel antialiasing should not be used on a
non-opaque surface. As I understand the vImage in
CGLVolatileSurfaceManager is not related directly to our window. For a
start, I have hardcoded Transparency.OPAQUE, but it requires much
better understanding of the architecture to make a more proper solution.
It is related to the CGLOffScreenSurfaceData, which is used as a surface
for VolatileImages. I check this code and looks like we ignore type of
the ColorModel and create a transparent native texture anyway.
3. When I started using CGGI_CopyImageFromCanvasToRGBInfo as a
rendering mode, I had found that the little endian mode should be
undefined. Again, it might be an improper way to do this.
It seems __LITTLE_ENDIAN__usage in this file should be checked.
Thank you,
Denis.
diff -r f87c5be90e01
src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java
---
a/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaFri
Jun 20 10:15:30 2014 -0700
+++
b/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaWed
Jul 09 14:50:09 2014 +0400
@@ -108,7 +108,7 @@
} else {
CGLGraphicsConfig gc =
(CGLGraphicsConfig)vImg.getGraphicsConfig();
-ColorModel cm = gc.getColorModel(vImg.getTransparency());
+ColorModel cm = gc.getColorModel(Transparency.OPAQUE);
int type = vImg.getForcedAccelSurfaceType();
// if acceleration type is forced (type != UNDEFINED)
then
// use the forced type, otherwise choose one based on
caps
diff -r f87c5be90e01 src/macosx/native/sun/font/CGGlyphImages.m
--- a/src/macosx/native/sun/font/CGGlyphImages.mFri Jun 20 10:15:30
2014 -0700
+++ b/src/macosx/native/sun/font/.mWed Jul 09 14:50:09 2014 +0400
@@ -196,6 +196,8 @@
#pragma mark --- Font Rendering Mode Descriptors ---
+#undef __LITTLE_ENDIAN__
+
static inline void
CGGI_CopyARGBPixelToRGBPixel(const UInt32 p, UInt8 *dst)
{
@@ -366,7 +368,8 @@
canvas-context = CGBitmapContextCreate(canvas-image-data,
width, height, 8, bytesPerRow,
colorSpace,
- kCGImageAlphaPremultipliedFirst);
+ kCGImageAlphaPremultipliedFirst
+| kCGBitmapByteOrder32Host);
CGContextSetRGBFillColor(canvas-context, 0.0f, 0.0f, 0.0f, 1.0f);
CGContextSetFontSize(canvas-context, 1);
--
Best regards, Sergey.
