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

Reply via email to