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