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

[Jim Graham]

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

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