[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
