Re: [OpenJDK 2D-Dev] Fwd: JDK bug 8078516
Ok, am asking since subpixel rendering works and is usable in most situations, except for the odd corner case when drawing over existing content in transparent surfaces. See eg. this screenshot of netbeans, with nice subpixel rendered text in the editor, while the labels on the buttons at the bottom have artifacts since they for some reason are drawn twice. [image: Inline images 1] On 2 August 2016 at 00:49, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > Phil will be able to comment on this further. All I can confirm is that > 8078526 is closed as a duplicate of 8087201, so it is no longer an open bug. > > -- Kevin > > > Torgeir Veimo wrote: > > I'm fairly sure it's the correct bug id, although I don't have access to > view it myself. > > Bug 8078526 is about supporting (without artifacts) subpixel rendering to > transparent surfaces. > > Bug 8087201 is about speeding up subpixel rendering. > > On 2 August 2016 at 00:39, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > >> Are you sure you have the right Bug ID? That bug (which is not publicly >> visible), is closed as a duplicate of 8087201, which was fixed in JDK 9 and >> 8u66 over a year ago. >> >> -- Kevin >> >> >> >> Torgeir Veimo wrote: >> >>> Is there any more work done on JDK bug 8078516? >>> -- >>> -Tor >> >> > > -- > -Tor > > -- -Tor
[OpenJDK 2D-Dev] Fwd: JDK bug 8078516
I'm fairly sure it's the correct bug id, although I don't have access to view it myself. Bug 8078526 is about supporting (without artifacts) subpixel rendering to transparent surfaces. Bug 8087201 is about speeding up subpixel rendering. On 2 August 2016 at 00:39, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > Are you sure you have the right Bug ID? That bug (which is not publicly > visible), is closed as a duplicate of 8087201, which was fixed in JDK 9 and > 8u66 over a year ago. > > -- Kevin > > > > Torgeir Veimo wrote: > >> Is there any more work done on JDK bug 8078516? >> -- >> -Tor > > -- -Tor
[OpenJDK 2D-Dev] JDK bug 8078516
Is there any more work done on JDK bug 8078516? -- -Tor
Re: [OpenJDK 2D-Dev] [9] request for review: 8087201: OGL: rendering of lcd text is slow
Ok, here's a comparison; jdk9 b70 on the left, apple's jdk 1.6 on the right; https://dl.dropboxusercontent.com/u/6299520/Screen%20Shot%202015-06-28%20at%2012.51.45%20pm.png The non-subpixel AA font is noticeable thinner for jdk9. This has been an issue brought up at various forums about jdk7/8's AA font rendering. On 22 June 2015 at 21:07, Andrew Brygin andrew.bry...@oracle.com wrote: Honestly, I have used Apple jdk6 as a reference, but have not compared the AA glyphs with native OSX apps. We have got exactly same AA glyphs in jdk8 and jdk9 as in Apple jdk. I have also verified that theses glyphs are exactly same as they are produced by the CoreText in our native code (i.e. we do not corrupt them in our rendering pipelines). So, I do not expect any effect on AA glyphs here. Thanks, Andrew. 19/06/15 18:45, Torgeir Veimo wrote: Ok, thank you for your feedback. A quick follow up question; could font rendering without subpixel antialiasing also benefit from the recent work, eg. the font renderer in jdk 8 produces glyphs that are much thinner than normal OSX font rendering. On 20 June 2015 at 01:27, Andrew Brygin andrew.bry...@oracle.com wrote: Hello Torgeir, thanks a lot for trying the fix with netbeans. According to the benchmarks, the fix should provide some improvement on system with modern Intel graphics boards. Unfortunately, the effect of the fix highly depends on graphics hardware capabilities: on some system the price of synchronized access to a texture is too high, and it may eliminate any performance benefits. For example, on iMac with ati rradeon hd6750m our benchmarks show increasing the rendering speed to 7-10 times, but it barely enough to smooth rendering. I am still looking for another possible solutions. Regarding the double painted text, in the case of lcd text we are unable to honor the SRC composite rule, and existing content of a destination surface affects a result of the rendering. So, double painting needs to be avoided. Thanks, Andrew On 6/19/2015 7:00 AM, Torgeir Veimo wrote: This patch dramatically speeds up subpixel font rendering on OSX in netbeans! It even makes netbeans usable on intel integrated graphics on retina screens! Excellent work! It also makes netbeans scrolling butter smooth when not using subpixel rendering. I saw one glitch when trying it out with intel graphics, see screenshot of netbeans; https://dl.dropboxusercontent.com/u/6299520/Screen%20Shot%202015-06-19%20at%2012.35.38%20pm.png I haven't been able to reproduce it after restarting netbeans. My jdk9 is stock from HG as of 20150619, with the patches from http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/ http://cr.openjdk.java.net/~bae/8087201/9/webrev.00/ http://cr.openjdk.java.net/~denis/8041900/webrev.00/ I still have to comment out line 410 in src/java.desktop/share/classes/sun/java2d/opengl/OGLSurfaceData.java: sg2d.surfaceData.getTransparency() == Transparency.OPAQUE to enable subpixel antialiasing in netbeans. The above glitch was when the above change was _not_ applied though (so not with subpixel rendering). https://bugs.openjdk.java.net/browse/JDK-8078516 is still private? I have not seen any artifact with subpixel rendering when enabling subpixel rendering btw, except for some text rendered double, but I think that's a netbeans issue; https://bugzilla-attachments-216655.netbeans.org/bugzilla/attachment.cgi?id=153905 On 19 June 2015 at 00:40, Andrew Brygin andrew.bry...@oracle.com wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8087201 Webrev: http://cr.openjdk.java.net/~bae/8087201/9/webrev.00/ Thanks, Andrew 18/06/15 17:39, Andrew Brygin пишет: Hello, could you please review a fix for 8087201? The root of the problem is that we have to supply a content of destination surface to lcd shader to compose the lcd glyph correctly. In order to do this, we have to copy a sub-image from destination buffer to an intermediate texture using glCopyTexSubImage2D() routine. Unfortunately, this routine is quite slow on majority of systems, and it dramatically reduces the overall speed of lcd text rendering. The main idea of the fix is to use a texture associated with the destination surface if it exists. In this case we have a chance to completely abandon the data copying. However, we have to avoid read-after-write in order to get correct results in this case. Fortunately, it can be achieved by using the GL_NV_texture_barrier extension: https://www.opengl.org/registry/specs/NV/texture_barrier.txt Beside this, suggested fix introduces following changes in OGL text renderer: * Separate accelerated caches for LCD and AA glyphs We have a single cache which is initialized ether for LCD or for AA glyphs. If application mixes these types of font smoothing from some reasons, we have got
[OpenJDK 2D-Dev] Fwd: [9] request for review: 8087201: OGL: rendering of lcd text is slow
It might actually be the subpixel AA in jdk9 b70 that is slightly thicker. Here's another shot; jdk9 b70, apple jdk1.6 subpixel AA and apple jdk 1.6 non-subpixel AA; https://dl.dropboxusercontent.com/u/6299520/Screen%20Shot%202015-06-28%20at%201.09.34%20pm.png On 28 June 2015 at 12:54, Torgeir Veimo torgeir.ve...@gmail.com wrote: Ok, here's a comparison; jdk9 b70 on the left, apple's jdk 1.6 on the right; https://dl.dropboxusercontent.com/u/6299520/Screen%20Shot%202015-06-28%20at%2012.51.45%20pm.png The non-subpixel AA font is noticeable thinner for jdk9. This has been an issue brought up at various forums about jdk7/8's AA font rendering. On 22 June 2015 at 21:07, Andrew Brygin andrew.bry...@oracle.com wrote: Honestly, I have used Apple jdk6 as a reference, but have not compared the AA glyphs with native OSX apps. We have got exactly same AA glyphs in jdk8 and jdk9 as in Apple jdk. I have also verified that theses glyphs are exactly same as they are produced by the CoreText in our native code (i.e. we do not corrupt them in our rendering pipelines). So, I do not expect any effect on AA glyphs here. Thanks, Andrew. 19/06/15 18:45, Torgeir Veimo wrote: Ok, thank you for your feedback. A quick follow up question; could font rendering without subpixel antialiasing also benefit from the recent work, eg. the font renderer in jdk 8 produces glyphs that are much thinner than normal OSX font rendering. On 20 June 2015 at 01:27, Andrew Brygin andrew.bry...@oracle.com wrote: Hello Torgeir, thanks a lot for trying the fix with netbeans. According to the benchmarks, the fix should provide some improvement on system with modern Intel graphics boards. Unfortunately, the effect of the fix highly depends on graphics hardware capabilities: on some system the price of synchronized access to a texture is too high, and it may eliminate any performance benefits. For example, on iMac with ati rradeon hd6750m our benchmarks show increasing the rendering speed to 7-10 times, but it barely enough to smooth rendering. I am still looking for another possible solutions. Regarding the double painted text, in the case of lcd text we are unable to honor the SRC composite rule, and existing content of a destination surface affects a result of the rendering. So, double painting needs to be avoided. Thanks, Andrew On 6/19/2015 7:00 AM, Torgeir Veimo wrote: This patch dramatically speeds up subpixel font rendering on OSX in netbeans! It even makes netbeans usable on intel integrated graphics on retina screens! Excellent work! It also makes netbeans scrolling butter smooth when not using subpixel rendering. I saw one glitch when trying it out with intel graphics, see screenshot of netbeans; https://dl.dropboxusercontent.com/u/6299520/Screen%20Shot%202015-06-19%20at%2012.35.38%20pm.png I haven't been able to reproduce it after restarting netbeans. My jdk9 is stock from HG as of 20150619, with the patches from http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/ http://cr.openjdk.java.net/~bae/8087201/9/webrev.00/ http://cr.openjdk.java.net/~denis/8041900/webrev.00/ I still have to comment out line 410 in src/java.desktop/share/classes/sun/java2d/opengl/OGLSurfaceData.java: sg2d.surfaceData.getTransparency() == Transparency.OPAQUE to enable subpixel antialiasing in netbeans. The above glitch was when the above change was _not_ applied though (so not with subpixel rendering). https://bugs.openjdk.java.net/browse/JDK-8078516 is still private? I have not seen any artifact with subpixel rendering when enabling subpixel rendering btw, except for some text rendered double, but I think that's a netbeans issue; https://bugzilla-attachments-216655.netbeans.org/bugzilla/attachment.cgi?id=153905 On 19 June 2015 at 00:40, Andrew Brygin andrew.bry...@oracle.com wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8087201 Webrev: http://cr.openjdk.java.net/~bae/8087201/9/webrev.00/ Thanks, Andrew 18/06/15 17:39, Andrew Brygin пишет: Hello, could you please review a fix for 8087201? The root of the problem is that we have to supply a content of destination surface to lcd shader to compose the lcd glyph correctly. In order to do this, we have to copy a sub-image from destination buffer to an intermediate texture using glCopyTexSubImage2D() routine. Unfortunately, this routine is quite slow on majority of systems, and it dramatically reduces the overall speed of lcd text rendering. The main idea of the fix is to use a texture associated with the destination surface if it exists. In this case we have a chance to completely abandon the data copying. However, we have to avoid read-after-write in order to get correct results in this case. Fortunately, it can be achieved by using the GL_NV_texture_barrier extension: https://www.opengl.org/registry
Re: [OpenJDK 2D-Dev] [9] request for review: 8087201: OGL: rendering of lcd text is slow
This patch dramatically speeds up subpixel font rendering on OSX in netbeans! It even makes netbeans usable on intel integrated graphics on retina screens! Excellent work! It also makes netbeans scrolling butter smooth when not using subpixel rendering. I saw one glitch when trying it out with intel graphics, see screenshot of netbeans; https://dl.dropboxusercontent.com/u/6299520/Screen%20Shot%202015-06-19%20at%2012.35.38%20pm.png I haven't been able to reproduce it after restarting netbeans. My jdk9 is stock from HG as of 20150619, with the patches from http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/ http://cr.openjdk.java.net/~bae/8087201/9/webrev.00/ http://cr.openjdk.java.net/~denis/8041900/webrev.00/ I still have to comment out line 410 in src/java.desktop/share/classes/sun/java2d/opengl/OGLSurfaceData.java: sg2d.surfaceData.getTransparency() == Transparency.OPAQUE to enable subpixel antialiasing in netbeans. The above glitch was when the above change was _not_ applied though (so not with subpixel rendering). https://bugs.openjdk.java.net/browse/JDK-8078516 is still private? I have not seen any artifact with subpixel rendering when enabling subpixel rendering btw, except for some text rendered double, but I think that's a netbeans issue; https://bugzilla-attachments-216655.netbeans.org/bugzilla/attachment.cgi?id=153905 On 19 June 2015 at 00:40, Andrew Brygin andrew.bry...@oracle.com wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8087201 Webrev: http://cr.openjdk.java.net/~bae/8087201/9/webrev.00/ Thanks, Andrew 18/06/15 17:39, Andrew Brygin пишет: Hello, could you please review a fix for 8087201? The root of the problem is that we have to supply a content of destination surface to lcd shader to compose the lcd glyph correctly. In order to do this, we have to copy a sub-image from destination buffer to an intermediate texture using glCopyTexSubImage2D() routine. Unfortunately, this routine is quite slow on majority of systems, and it dramatically reduces the overall speed of lcd text rendering. The main idea of the fix is to use a texture associated with the destination surface if it exists. In this case we have a chance to completely abandon the data copying. However, we have to avoid read-after-write in order to get correct results in this case. Fortunately, it can be achieved by using the GL_NV_texture_barrier extension: https://www.opengl.org/registry/specs/NV/texture_barrier.txt Beside this, suggested fix introduces following changes in OGL text renderer: * Separate accelerated caches for LCD and AA glyphs We have a single cache which is initialized ether for LCD or for AA glyphs. If application mixes these types of font smoothing from some reasons, we have got a significant performance degradation. For example, if we use J2DBench in GUI mode, then swing GUI initializes the accelerated cache for AA, and subsequent rendering of LCD text always uses 'no-cache' code path. * Increase dimension of the glyph cache cell from 16x16 to 32x32. This change gives significant performance boost on systems with retina (because of average size of rendered glyphs). However, on systems where the fast path with destination texture is not possible for any reasons, this change may cause a performance degradation because of more extenceive usage of glCopyTexSubImage2D. So, we probably may want to get a means to configure the cell dimension depending on system capabilities. Performance results overview: * MBP with Intel Iris (retina, texture barrier is available): http://cr.openjdk.java.net/~bae/8087201/9/mbp-intel-iris.txt * iMac with AMD HD6750M (no retina, texture barrier is available): http://cr.openjdk.java.net/~bae/8087201/9/imac-amd-hd6750m.txt * MBP with OSX10.8, NV GF9600M (no retina, no texture barrier): http://cr.openjdk.java.net/~bae/8087201/9/mbp-10.8-NVGF9600M.txt Please take a look. Thanks, Andrew -- -Tor
[OpenJDK 2D-Dev] Fwd: AWT Dev [9] Review Request: JDK-8041900 [macosx] Java forces the use of discrete GPU
Same here, 2014 15 macbook pro. Running netbeans with openjdk from hg yesterday with this patch applied. On 28/05/2015, Sergey Bylokhov sergey.bylok...@oracle.com wrote: Hi, Denis. Can you describe the steps on how to test it. On my mac it still change the vc. On 27.05.15 17:16, Denis Fokin wrote: Please review the fix for jdk9 The fix allows do not force discrete video card usage on MacBook Pro models with two video cards. I have tested the fix on several MPBs. Bug: https://bugs.openjdk.java.net/browse/JDK-8041900 Webrev: http://cr.openjdk.java.net/~denis/8041900/webrev.00 http://cr.openjdk.java.net/%7Edenis/8041900/webrev.00 -- Best regards, Sergey. -- -Tor
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 + 0
Re: [OpenJDK 2D-Dev] AWT Dev [9] Review Request: JDK-8041900 [macosx] Java forces the use of discrete GPU
This is one of the bugs that prevent IDEA to switching to JDK7/8 for IntelliJ by default. The JDK is perceived by a lot of users as an ill-behaved application on OS X because it forces use of the discrete GPU, drastically reducing battery life. This patch didn't work for me either, on a 2014 15 retina mbp. On 28 May 2015 at 07:53, Phil Race philip.r...@oracle.com wrote: Hello Denis, Once lots of people start to use the integrated CPU I suppose there is a non-zero likelihood of crashes and other problems with that too. I would like to see this (a) selected based on battery or similar, not fixed, (b) made controllable by a flag or similar, and once that is done, get a lot of JDK9 bake time. To be suitable for JDK 8u it would have to be off by default. -phil. On 05/27/2015 02:44 PM, Denis Fokin wrote: Hi Phil, Thank you for the comments. Actually, the battery life is not the only issue that experience our customers. I am getting crash reports that are reproducible only with discrete cards on MBP. Some users report hangs with discrete cards. All this issues are eliminated by switching on the integrated GPU. I am not sure, that discrete card gives significant performance improvement in jdk implementation. Other applications, like Chrome, use discrete video card only for WebGl or similar tasks. Thank you, Denis 27 мая 2015 г., в 21:09, Phil Race philip.r...@oracle.com написал(а): I suppose that NSOpenGLPFAAllowOfflineRenderers must prevent whatever 'tickling' of the discrete GPU we do from automatically making it the active GPU ? This seems to merit a source code comment as at face value it seems like an API that allows you to use that (other) discrete GPU alongside the active GPU, but so we don't need that part, just the side-effect behaviour. But do we want this fix in this form ? The integrated GPU is going to perform far less well than the discrete GPU. If the issue is battery life, then perhaps it should be tied to whether we are running on battery or mains power. And then perhaps you need to figure out how to switch GPU on the fly when you go from mains to battery. -phil. On 05/27/2015 08:08 AM, Denis Fokin wrote: Hi, Sergey, Basically, you should close all apps that can switch the vc including the utility for switching video cards. Make sure in About This Mac - Displays that the integrated card is enabled. Start an application with the patched version of Java. Check About This Mac - Displays. Integrated video card should be still active. 27 мая 2015 г., в 17:30, Sergey Bylokhov sergey.bylok...@oracle.com написал(а): Hi, Denis. Can you describe the steps on how to test it. On my mac it still change the vc. On 27.05.15 17:16, Denis Fokin wrote: Please review the fix for jdk9 The fix allows do not force discrete video card usage on MacBook Pro models with two video cards. I have tested the fix on several MPBs. Bug: https://bugs.openjdk.java.net/browse/JDK-8041900 Webrev: http://cr.openjdk.java.net/~denis/8041900/webrev.00 http://cr.openjdk.java.net/%7Edenis/8041900/webrev.00 -- Best regards, Sergey. -- -Tor
[OpenJDK 2D-Dev] Fwd: [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON
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 + 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
