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

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Java's definition of the SRC operator
From:       james.graham () oracle ! com (Jim Graham)
Date:       2011-02-09 23:19:37
Message-ID: 4D532109.9040505 () oracle ! com
[Download RAW message or body]

[Resending - I forgot to CC the list when I sent it originally...]

Hi Clemens,

What your code should do is draw either a black or a red line for the 
first (Src) case and then a red line for the second (SrcOver) case.

The black or red choice comes down to whether or not the opaque 
destination declares that it stores premultiplied data or not.  The 
results of the blend are in premultiplied space and so will be (1,0,0,1) 
out of 255 for the Src result.  That is then converted back into the 
"premultiplied or not" style of the destination and then stored without 
alpha.  Most, if not all, of our opaque destinations declare themselves 
as non-premultiplied so the result should be divided back out to (255, 
0, 0, 1) and then stored as red (modulo AA coverage calculations), but 
it seems like we have some bugs there.

If I run the code on screen I get a black line which would indicate that 
it is left in the premultiplied form even though the ColorModel says 
that it is non-premultiplied.  (I believe I am talking to the D3D 
pipeline there and I think we punted on this particular aspect of 
compatibility - we should be returning opaque colormodels that claim to 
be premultiplied, but we are not).  So, the screen gets it right except 
for agreeing with the premultiplied attribute of its ColorModel.

If I create a TYPE_INT_RGB BufferedImage then nothing is drawn which is 
a bug from my perspective regardless of premultiplied issues.

Neither case does what I think is the correct answer which is to store 
opaque red (modulated by AA coverage), though the screen is closer if it 
just returned the right answer from its ColorModel...

			...jim

On 11/2/2010 4:27 AM, Clemens Eisserer wrote:
> Hi Jim,
>
> I still don't understand why pixels without full aa coverage take the
> src's alpha into account.
> Is this intentional?
>
> Thanks, Clemens
>
>> Hi Jim,
>>
>>> blendresult = PORTER_DUFF(rule, rendercolor, dstcolor, extraalpha)
>>> // For SRC, blendresult = rendercolor modulated by extra alpha
>>> storedresult = INTERP(dstcolor, blendresult, aacoverage)
>>> // For full aa coverage, storedresult = blendresult
>>>
>>> The only part of this that could possibly be interpreted as "behaving like
>>> SRC_OVER" would be the second INTERP and it depends on the aa coverage, not
>>> on the alpha of the colors involved.  Is that what they were talking about?
>>
>> Thanks for the detailed explanation.
>>
>> What confuses me is that pixels wich don't have full AA coverage take
>> the src's alpha into the calculation.
>>
>> Shouldn't the following operations both yield the same result when
>> rendered to an opaque destination?
>>
>>       /*SRC*/
>>       g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC));
>>       g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,RenderingHints.VALUE_ANTIALIAS_ON);
>>       g2d.setColor(new Color(255, 0, 0, 1));
>>       g2d.drawLine(100, 120, 200, 220);
>>
>>       /*SRC_OVER*/
>>       g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER));
>>       g2d.setColor(Color.red);
>>       g2d.drawLine(100, 140, 200, 240);
>>
>> Thanks, Clemens
>>

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