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

[Jim Graham]

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
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>
>