[OpenJDK 2D-Dev] [9] request for review: 8087201: OGL: rendering of lcd text is slow

[Andrew Brygin]

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 at 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
>>
>
>