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

[Jim Graham]

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
>>