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
