[OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha

[Phil Race]

This fixes it, although the same may need to be done to OGL and D3D 
subclasses
of SurfaceData.java

-phil.

diff --git a/src/share/classes/sun/java2d/SurfaceData.java 
b/src/share/classes/sun/java2d/SurfaceData.java
--- a/src/share/classes/sun/java2d/SurfaceData.java
+++ b/src/share/classes/sun/java2d/SurfaceData.java
@@ -450,6 +450,7 @@ public abstract class SurfaceData
         // For now the answer can only be true in the following cases:
         if (sg2d.compositeState <= SunGraphics2D.COMP_ISCOPY &&
             sg2d.paintState <= SunGraphics2D.PAINT_ALPHACOLOR &&
+            sg2d.imageComp != CompositeType.Src &&
             sg2d.clipState <= SunGraphics2D.CLIP_RECTANGULAR &&
             sg2d.surfaceData.getTransparency() == Transparency.OPAQUE)
         {


Phil Race wrote:
> I didn't get time to look at this yesterday.
> I think the problem is (sort of) in SunGraphics2D.setComposite() where 
> we have
>
>                }
>            } else if (newCompType == CompositeType.SrcNoEa ||
>                       newCompType == CompositeType.Src ||
>                       newCompType == CompositeType.Clear)
>            {
>
> This then categorises the composite state "SRC" as COMP_ISCOPY
> regardless of whether there is an extra alpha.
>
> This code was introduced in  
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6248957
>
> I believe that there's some handling of the extra alpha for most 
> rendering but
> its enough to mislead SurfaceData into thinking it can create and use 
> LCD glyphs.
> I've not yet looked into what exactly happens after that but it
> seems like we end up  in a loop that uses the LCD glyph
> data as if its greyscale mask and you'll get garbage.
>
> If this is the case we can't rely on the compositeState variable and
> will need to check the composite type.
>
> -phil.
>
> Denis Lila wrote:
>> Hello.
>>
>> After noticing some weird things I made some modifications to
>> Clemens' test. I've attached the results and the tester.
>> The most interesting results are the first 18 lines in each
>> image, all of which are produced by rendering to INT_RBG type
>> buffered images. The first 6 lines have both AA_ON and subpixel aa.
>> Lines 7-12 have only subpixel AA, and lines 13-18 have only AA_ON.
>> In each group of 6, the only thing that changes is the order in
>> which the hints, the composite, and the colour are set.
>>
>> Lines 1-6 and 13-18 don't look right on closed jdk (1.6.0_21-b06).
>> The only thing they have in common is that the AA hint is on.
>> Lines 7-12 look ok - they only have LCD AA. We can see that the order
>> doesn't matter.
>>
>> On openJDK7 (with a build of a fresh clone of the 2d tree) lines
>> 1-3 look like what Clemens is seeing, but the next 3 don't look bad,
>> even though all of the first 6 lines are supposed to be drawn with
>> a black colour, SRC compositing, and both AA_ON and LCD AA.
>> The same goes for lines 13-15. What lines 1-3 and 13-15 have in
>> common is that the colour is set after the composite.
>> Lines 7-12 still look ok, but they are a bit different from what closed
>> java produces, even though subpixel antialiasing is clearly used in 
>> both.
>>
>> That's it for my observations.
>> Regards,
>> Denis.
>>
>> ----- "Clemens Eisserer" <linuxhippy at gmail.com> wrote:
>>
>>  
>>> Hi again,
>>>
>>> Attached is the sample program as well as the output I get on
>>> jdk7b99,
>>> when running the sample program attached.
>>>
>>> - Clemens
>>>    
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>