[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-2d-dev
Subject: [OpenJDK 2D-Dev] Fwd: [9] request for review: 8087201: OGL: rendering of lcd text is slow
From: Torgeir Veimo <torgeir.veimo () gmail ! com>
Date: 2015-06-28 3:11:33
Message-ID: CAG5Tc=V3j0=M99HwdpJMZt18L=i54ZeSPzNjNuTgvJDBMzLNNA () mail ! gmail ! com
[Download RAW message or body]
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.veimo@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.brygin@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.brygin@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.brygin@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic