D'oh!
The argb value supplied to the PixelConverter is a non-premultiplied
value by definition (you would not be able to extract a non-pre value
from an already-pre value so we supply it as non-pre and any
premultiplied destination must then apply the premultiplication when it
converts it to a pixel.
So, the PixelConverter.Xrgb is correct.
As Phil pointed out, this apparently does work on a BufferedImage, so
that confirms what my "uh oh, where's the bug that was reported?" logic
didn't realize...
Thanks to Chris for remembering the issues we talked about. In
retrospect, I think we wished we had originally defined our opaque image
types as "premultiplied with the missing alpha" instead of
"non-premultiplied cuz, like, what alpha are you talking about" for the
reasons he stated. I think the only "bug" would be whether an OGL
opaque surface supplies a ColorModel that claims it is premultiplied or
not. If it states that it is pre, then its behavior is correct...
...jim
On 10/2/13 3:03 PM, Jim Graham wrote:
From looking at the code, it looks like this is probably a bug. The
default color model for TYPE_INT_RGB is non-premultiplied which means
that we should have unmultiplied the alpha before we stored the color.
Now, if you had used an alpha of 0, then we would have been unable to
reverse any pre-multiplication step and the results would have been
undefined for practical reasons, but with an alpha even as low as 2, we
should have been able to reverse the multiplication to something other
than black.
It looks like the bug is in the PixelConverter.Xrgb class which just
returns the raw rgb value (misnomer, it is actually an argb value) as
the pixel without checking the pre-multiplied flag of the colormodel. We
should probably have an XrgbNonPre and XrgbPre to be more accurate.
At some point, I seem to recall discussions about our handling of
premultiplication for opaque surfaces and we realized that we were not
doing it quite right, and I seem to recall throwing our hands up in
frustration but I don't remember why we didn't clean this up (gettin'
too old now...) :(
...jim
On 9/30/13 10:52 PM, Clemens Eisserer wrote:
Hi,
I am currently testing compatibility of the xrender pipeline with
different composition operations, and I noticed for AlphaComposite.SRC
the D3D and OGL pipelines store pre-multiplied colors in surfaces
without an alpha-channel.
For example the following code results in a black rectangle, instead
of a red one when rendering to a BufferedImage of type INT_RGB:
((Graphics2D) g).setComposite(AlphaComposite.Src);
g.setColor(new Color(255, 0, 0, 2));
g.fillRect(10, 10, 100, 100);
Is this intentional or should it be considered a bug?
Thanks, Clemens
