[OpenJDK 2D-Dev] Handling of premultication in the D3D & OGL pipelines
james.graham at oracle.com
Wed Oct 2 22:03:50 UTC 2013
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
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