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

Chris Campbell campbell at plausible.coop
Wed Mar 25 17:24:33 UTC 2015


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



More information about the 2d-dev mailing list