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/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 -- -Tor