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
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 lo
[I just saw Jim's reply but here's what I was going to send anyway].
On 9/30/2013 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-mu
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
BTW, before you stumble upon XOR XRender bug yourself - I'm currently
working on it and will send a fix for review shortly.
Thanks,
Vadim
On 01.10.2013 9:52, Clemens Eisserer wrote:
Hi,
I am currently testing compatibility of the xrender pipeline with
different composition operations, and I n
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, ins
