Hi guys, I haven't looked at the code in question in quite a while, but my recollection is that the OGL (and D3D) pipelines treated all surfaces -- including opaque ones -- as premultiplied because the OpenGL blend modes weren't flexible enough to replicate the equations used in our software loops. I seem to recall taking advantage of the lack of a strict specification for this particular case and I made the OGL pipeline do whatever would allow for the fastest rendering, even if that meant it didn't produce exactly the same results as the software loops.
Just like Jim, I remember some break-room discussion as to what the "correct" behavior should be for this case, but I don't think we reached a conclusion. I think there might even have been a bug report filed that talks about these discrepancies, but I can't seem to fi… Oh, wait, here's something! http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5051225 That seems to align with what Jim and I remember, but unfortunately it doesn't go into too much detail about the "analysis" the ensued, and my memory's not getting any younger either :D Chris On Oct 2, 2013, at 3:03 PM, Jim Graham <james.gra...@oracle.com> 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 >>
