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
