[OpenJDK 2D-Dev] Handling of premultication in the D3D & OGL pipelines
james.graham at oracle.com
Thu Oct 3 01:42:53 UTC 2013
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
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...
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...) :(
> On 9/30/13 10:52 PM, Clemens Eisserer wrote:
>> 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
More information about the 2d-dev