[OpenJDK 2D-Dev] Handling of premultication in the D3D & OGL pipelines

Jim Graham 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 
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:
> 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

More information about the 2d-dev mailing list