[OpenJDK 2D-Dev] Java's definition of the SRC operator
james.graham at oracle.com
Wed Feb 9 15:19:37 PST 2011
[Resending - I forgot to CC the list when I sent it originally...]
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...
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?
>> g2d.setColor(new Color(255, 0, 0, 1));
>> g2d.drawLine(100, 120, 200, 220);
>> g2d.drawLine(100, 140, 200, 240);
>> Thanks, Clemens
More information about the 2d-dev