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

[Andrew Brygin]

Hello Phil,

  could you please take a look to updated version of the fix?

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

* CGGlyphImages.m
  The main part of the recent changes is related to generation of LCD 
glyph images.
  With previous version of the fix we produced lcd glyphs which were quite
  close to jdk6 results if we render dark text on light background 
(black on white
  as an extreme case).
  However, it was discovered that in the case of light text on dark 
background,
  our results had significant differences  comparing with jdk6.
  In order to reduce the difference, now we produce two separate glyph 
images
  (black-on-white and white-on-black), blend them, and then pass the blended
  glyph image to text pipes. This approach seems to give an acceptable  
results
  for both light and dark cases.

*  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


On 12/12/2014 8:11 PM, Andrew Brygin wrote:
> Hello Phil,
>
>  at the moment, I failed to get acceptable results for rendering to 
> translucent destination.
>  I am playing with an idea to fall back to grayscale AA on non-opaque 
> pixels (or pixels with
>  opacity less than a certain threshold) directly in the lcd shader 
> program.
>
>  For now, there is an updated version of the fix which supports lcd 
> text in OGL pipeline
>  for a case of  alpha paint and default composite. However, the case 
> of translucent
>  destination is not supported yet, that makes lcd text unavailable in 
> swing apps
>  on macosx.
>
>  All changes specific for this version are in OGLSurfaceData.java and 
> OGLTextRenderer.c.
>  Rest of the fix is unchanged.
>
> http://cr.openjdk.java.net/~bae/8023794/9/webrev.04/
>
>  Of course,  this version may affect the performance of lcd text 
> rendering, but
>  I have no numbers to estimate the effect at the moment. In the worst 
> case,
>  we can consider to use two different programs: one for opaque paint 
> (in order
>  to preserve performance), and another (like published now) for the 
> case of alpha
>  paint.
>
>  Please take a look.
>
> Thanks,
> Andrew
>
> On 10/25/2014 12:03 AM, Phil Race wrote:
>> On 10/24/2014 10:56 AM, Andrew Brygin wrote:
>>> Hello,
>>>
>>>  please take a look to updated version of the fix:
>>>
>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/
>>>
>>>  TODOs were removed:
>>>  * CGLSurfaceData.java
>>>       the condition for lcd rendering is inherited from OGL surface 
>>> data, but
>>>       here we have to remove the check for the transparency, because 
>>> we always
>>>       create transparent  volatile images for swing backbuffers on 
>>> macosx in order
>>>       to support shaped windows.
>>
>> Are you saying its created translucent regardless, or only if its 
>> shaped?
>> But if its really translucent/transparent under the text, then
>> IIRC the shaders - and s/w loops - do not properly handle that case.
>> You probably should try drawing LCD text over a fully transparent area
>> to see what happens.
>>
>>>
>>> * * *CGGlyphImages.m and AWTStrike.m
>>>       NSException is used to  handle invalid (unevaluated) text 
>>> antialising hint values.
>>>       We actually have already used NSException to handle memory 
>>> allocation failure,
>>>       so this change just makes usage of get/release of primitive 
>>> arrays a bit more safe.
>>>
>>>
>>> Known differences comparing to apple jdk6:
>>>
>>> a) we do not interpret TEXT_ANTIALIASING_ON as lcd text.
>>
>> Its should never have meant that, else you would have no way to 
>> explicitly
>> request grey scale.
>>>
>>> b) we do not render lcd text in a case of non-opaque paint. This 
>>> behavior is common for
>>>      all cases (software loops, OGL, and D3D), so it seems to 
>>> deserve a separate bug if we
>>>      want to handle this case.
>>
>> I think that's another manifestation of the issue mentioned above.
>>
>> -phil.
>>
>