[OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON

[Andrew Brygin]

Hi Chris,

  thank you for the comments and explanation. I have updated the 
OGLContext_IsLCDShaderSupportAvailable()
  and comments in OGLTextRenderer.c accordingly:

http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/

  Good to know that you keep an eye on the OGL pipeline :)

Thanks,
Andrew

On 3/25/2015 8:24 PM, Chris Campbell wrote:
> Hi Andrew,
>
> That's a good find re: pow().  In the comment at lines 277-283 I 
> mentioned that there was only a scalar variant of pow().  I wonder if 
> that was a limitation in some early version of GLSL I was using or 
> perhaps some driver bug/restriction.  According to all the docs I can 
> find the vector variants have been there all along:
> https://www.opengl.org/sdk/docs/man4/index.php
>
> So now I'm wondering if the slowness was actually due to me trying 3 
> scalar pow() calls versus one vector pow() call.
>
> Oh, aha!  I think this explains part of it:
>
>  269  * This is the GLSL fragment shader source code for rendering 
> LCD-optimized
>  270  * text.  Do not be frightened; it is much easier to understand 
> than the
>  271  * equivalent ASM-like fragment program!
>
> Looks like I wrote the original version of this shader using the 
> GL_ARB_fragment_program language, which indeed only had a scalar POW 
> instruction (see section 3.11.5.20):
> https://www.opengl.org/registry/specs/ARB/fragment_program.txt
>
> And then I'm guessing that when I rewrote it in more modern GLSL, I 
> didn't notice that pow() supported vectors.  Sigh.  That 3D texture 
> LUT was a lot of work for a whole lot of nothing.
>
> In any case, you might want to rewrite the comment at lines 277-283 to 
> suit the new code.  Same goes for the comment at line 315:
>
>     // gamma adjust the dest color using the invgamma LUT
>
> Also, I noticed that the restrictions in 
> OGLContext_IsLCDShaderSupportAvailable() could be loosened since you 
> only need 2 texture units now.  Just in the extremely unlikely case 
> that anyone's running this stuff on ancient hardware :)
>
> Thanks,
> Chris
>
>
> Andrew Brygin wrote:
>> Hello Phil,
>>
>> could you please take a look to updated version of the fix?
>>
>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
>>
>> * OGLTextRenderer.c
>> It was discovered, that in some cases lcd glyphs had visible 'dark
>> border' around.
>> This border appeared due to the gamma correction in lcd shader, which
>> uses lookup
>> on 3D texture instead of using 'pow' routine. The texture is populated
>> with significant
>> granularity (16 points per edge), what is a root cause of rough
>> interpolation of color values.
>> Suggested change is to eliminate the interpolation and use 'pow' routine
>> directly.
>> It gives more accurate color values, and does not introduce significant
>> performance hit
>> (see benchmark summary below).
>> However, this part of the fix affects not only macosx, but any platform
>> where OGL text
>> shader can be used, so it probably worth to split into a separate fix.
>>
>> Summary:
>> lcd-ogl-3Dlookup:
>> Number of tests: 4
>> Overall average: 42.68027553311743
>> Best spread: 3.49% variance
>> Worst spread: 29.59% variance
>> (Basis for results comparison)
>>
>> lcd-ogl-pow:
>> Number of tests: 4
>> Overall average: 42.468941501367084
>> Best spread: 2.51% variance
>> Worst spread: 29.44% variance
>> Comparison to basis:
>> Best result: 103.28% of basis
>> Worst result: 97.36% of basis
>> Number of wins: 1
>> Number of ties: 2
>> Number of losses: 1
>>
>> Thanks,
>> Andrew
>>
>>