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

[Sergey Bylokhov]

The fix looks fine to me. It will be good if an SQE team will port this 
test to the jdk ws.

On 27.03.15 17:50, Andrew Brygin wrote:
> There is a minor update in the fix: it does not worth to blend 
> black-on-white
> and white-on-black glyphs for the case of AA glyphs, because it makes 
> no difference.
> CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794:
>
> http://cr.openjdk.java.net/~bae/8023794/9/webrev.08
>
> I have also modified the AntialiasDemo a bit in order to render the
> sample text in different colors, and in order to render into a volatile
> image as well:
> http://cr.openjdk.java.net/~bae/8023794/demo/AntialiasDemo.java
>
> It could be used to assess the change in glyph generation.
>
> Thanks,
> Andrew
>
> On 3/26/2015 3:59 PM, Andrew Brygin wrote:
>> 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
>>>>
>>>>
>>
>


-- 
Best regards, Sergey.