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

[Phil Race]

Hi Andrew,

Overall the fix looks good. A few questions.

1. Regarding translucent surfaces, do you know when Swing
has a translucent backbuffer and when it does not ?
It has been noted that we now have LCD text in some cases
in SS2 but apparently still not in NB ..

2. Where are we likely to find (or not find) support for this extension ?

Based on your results ironically, it seems that the Nvidia card is the
one case that did not support the extension. Is that because it was
an older version of OS X than the others ?

3. The performance 'lost' case.
 >   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

Is this a reference to losing performance on non-retina displays
where we would be better off with the smaller cache cell size ?

I suppose the importance of this depends in part on the answer to 
question #2

4. Have you tried this on Linux .. or even a Windows OGL driver ?

-phil.

On 06/18/2015 07:40 AM, Andrew Brygin 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
>