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

[Sergey Bylokhov]

Hi, Andrew.
Can you additionally provide the bench data about aa(before/after the 
fix) vs new lcd lcd?

Probably it well be more obvious if the code in OGLTextRenderer
1007     if (OGLC_IS_CAP_PRESENT(oglc, CAPS_EXT_TEXBARRIER) &&
1008         dstOps->textureTarget == GL_TEXTURE_2D)

Will be moved to the separate method and the check to the possibility of 
fast blit will be clarified instead of:
if (dstTextureID == 0) {

Also your review request contains useful information like 
fast/slow/read-after-write etc. I think this information can be useful 
as a comments in the code.

On 18.06.15 17:39, Andrew Brygin wrote:
> 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


-- 
Best regards, Sergey.