Premultiplied alpha handle for driver

[Huang, FrankR]

Morton,

I have gotten the idea of the premultiplied alpha in image. Just as you told me, the driver thought the ARGB picture gives the premultiplied value. So the driver does not need to do the premultiplied pass.

According to my debug result, I have found that the geode driver has the wrong operation on OVER operation(compared correct result on X1200 driver). Let me take an example:
When I use the following function to do the rendering:
	XRenderComposite(dpy, PictOpOver, picture_1x1, 0, win->pict,0,0,0,0,0,0,50,50)
There is no mask, so the driver will use the picture_1x1's alpha value(picture_1x1 is a ARGB picture) to do the Over operation(A+(1-a)B). "A" is the picture_1x1, "B" is win->pict, and "a" is the alpha value of picture_1x1. No problem for this condition and the result is correct.

Another condition is with mask:
	XRenderComposite(dpy, PictOpOver, picture_1x1, mask, win->pict, 0,0,0,0,0,0,50,50)
The mask is a PICT_a8 picture, the driver will use mask's alpha value to do the Over operation(A+ (1-a)B).  "A" is the picture_1x1, "B" is win->pict, and "a" is the alpha value of mask.  But the wrong thing is that the driver omit the picture_1x1's alpha value. So the result is wrong. 

So I just want to know if picture_1x1 has the alpha value and mask has the alpha value. How the driver handle this? If I know the answer, I can fix this bug. Hope your reply soon:)


By the way, why the R cahnnel can not be greater than A channel. For example:
	Rendercolor.red = 40000;
	Rendercolor.green = 30000;
	Rendercolor.blue = 20000;
	Rendercolor.alpha = 50000;
	XRenderFillRectangle(dpy, PictOpSrc, picture_1x1, &rendercolor, 0, 0, 1, 1);

Thanks,
Frank

-----Original Message-----
From: Jonathan Morton [mailto:jonathan.morton at movial.com] 
Sent: 2010年6月1日 18:06
To: Huang, FrankR
Cc: xorg-devel at lists.x.org
Subject: Re: Premultiplied alpha handle for driver

On Mon, 2010-05-31 at 10:42 +0800, Huang, FrankR wrote:
> We know the premultiplied alpha will be used sometimes in blend. Is
> that used in the graphics driver?

XRender always expects premultiplied alpha in images.  Your previous
example, with ARGB values of (100,255,0,0) is therefore an invalid pixel
vector, since the R channel is greater than the A channel.

> And the picture_1x1[0] is a ARGB picture with an alpha value;
> mask_20x20[0] is a A8 picture with an alpha value.  How the
> driver(do_composite) handle this two alpha value?

Each component (A,R,G,B) of the source is multiplied by the mask value
before being applied to the main blend equation, as I explained
previously.  Assuming 8 bits per channel, the multiplication occurs as
if 255 == 1.0 and 128 == (128/255), which is usual for graphics.

The general formula is:  dst = (src IN mask) OP dst.

With component-alpha turned off, as is usual except for ClearType, src
and dst are expanded to ARGB format (with A set to 255 if not present in
the original format) and mask is cut down to it's alpha channel, before
any evaluation occurs.  Any missing channels are cut away from dst when
storing the result.

An example which may help you to understand, is that XRender can handle
un-premultiplied ARGB images by interpreting the same image as an XRGB32
source and an AXXX32 mask (specified as ARGB32) simultaneously.  The
result will be in premultiplied format.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com