Premultiplied alpha handle for driver
alexdeucher at gmail.com
Thu Jun 3 07:09:02 PDT 2010
2010/6/3 Huang, FrankR <FrankR.Huang at amd.com>:
> I have fix the OVER opearion on geode.
> For current bug, explain my solve method. I use two steps to finish the OVER rendering, the first step is to do the SRC*(alpha of MASK),the result is SRC'
> that is to say:
> SRC'r = SRCr * alpha of MASK
> SRC'g = SRCg * alpha of MASK
> SRC'b = SRCb * alpha of MASK
> SRC'a = SRCa * alpha of MASK
> I put the result to a off-screen FB regeion.The next step is to do SRC' + (1- SRC'a)DEST, because the screen is RGB565, so omit the SRC''a. that is to say:
> SRC''r = SRC'r + (1- SRC'a)DEST
> SRC''g = SRC'g + (1- SRC'a)DEST
> SRC''b = SRC'b + (1- SRC'a)DEST
> Taks an example:
> SRC = ARGB(0x949c4e27) MASK = A8(0x75)
> So SRC' = ARGB(0x43472311)
> Then SRC'' = RGB565...
> The bug before is that the driver does a a*A+ (1-a)*B for OVER opearation. It is absolutely wrong. The real OVER operation should be A+(1-a)*B.
> Attach three pictures for comparison. Still I will correct other bugs on rendering.
FWIW, when I was implementing render support in the radeon driver, I
found the source to rendercheck very helpful in understanding the math
involved, especially ops.c:
> Geodepro_old.PNG is the old driver result for progressbar.
> Geodepro.PNG is the new driver result for progressbar.
> X1200pro.png is the ATI X1200 result for progressbar.
> -----Original Message-----
> From: Jonathan Morton [mailto:jonathan.morton at movial.com]
> Sent: 2010年6月2日 2:02
> To: Siarhei Siamashka
> Cc: xorg-devel at lists.x.org; Huang, FrankR
> Subject: Re: Premultiplied alpha handle for driver
> On Tue, 2010-06-01 at 19:26 +0300, Siarhei Siamashka wrote:
>> On Tuesday 01 June 2010, Jonathan Morton wrote:
>> > 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.
>> This is not necessarily invalid. It's more like "additive blending" feature
>> which is even used by some people:
> Well, that's a corner case, but I was trying to get a conceptual point
> From: Jonathan Morton
> jonathan.morton at movial.com
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
More information about the xorg-devel