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

[Phil Race]

  On 10/29/2010 1:00 PM, Jim Graham wrote:
> Why is SRC with an extra alpha handled any differently than SrcNoEa 
> with a color that has alpha?  The two cases are supposed to be folded 
> together because it doesn't matter where the alpha comes from.
>
> There is also a paintType indicator that indicates when the paint is 
> opaque.  If you only register the loops for opaque paints then I think 
> the state may not be enough as you say, but if the loops can handle 
> alpha then they can handle Src with Ea...

Maybe that's the better answer than backing off to greyscale,
ie the LCD loops aren't registered in this case and they can/should be,
although I'm not sure they are currently set up to handle the Ea.

-phil.

>
>             ...jim
>
> On 10/29/10 12:36 PM, 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
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>