[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha
From:       philip.race () oracle ! com (Phil Race)
Date:       2010-10-29 22:14:14
Message-ID: 4CCB4736.9060901 () oracle ! com
[Download RAW message or body]

And in fact that is handled as the greyscale and lcd text loops use the 
alpha component
of the alpha colour on the graphics and SG2D appears to take care of 
this in calculating
the argb color.

And the garbage problem is due to a bug in surfacedata where that 
earlier b17 fix
I mentioned tested for paintState > PAINT_OPAQUECOLOR  instead of  > 
PAINT_ALPHACOLOR
and consequently selected a textpipe for greyscale instead of LCD glyphs.

So the better fix is this :-

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
@@ -545,7 +545,7 @@ public abstract class SurfaceData
                     sg2d.drawpipe = AAColorViaShape;
                     sg2d.fillpipe = AAColorViaShape;
                     sg2d.shapepipe = AAColorShape;
-                    if (sg2d.paintState > sg2d.PAINT_OPAQUECOLOR ||
+                    if (sg2d.paintState > sg2d.PAINT_ALPHACOLOR ||
                         sg2d.compositeState > sg2d.COMP_ISCOPY)
                     {
                         sg2d.textpipe = colorText;


I'd earlier postulated that the greyscale AA fast loops installed by the 
b17 fix
wouldn't handle this either but they can for the same reason.

-phil.


Jim Graham wrote:
> If you allow ALPHACOLOR (paintState <= ALPHACOLOR) then you should be 
> able to handle Src with EA...
>
>             ...jim
>
> On 10/29/10 12:49 PM, Phil Race wrote:
>> 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
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>>
>>>
>>


[prev in list] [next in list] [prev in thread] [next in thread]