GTK progressbar call on XRenderComposite

Huang, FrankR FrankR.Huang at amd.com
Fri May 28 00:34:53 PDT 2010


I found the cause of the rendering bug in geode driver.
When the source pict format is ARGB32 and the mask pict format is A8(our driver can only support PICT_a8 and PICT_a4), the result is wrong.
Now I want to ask a question here:
	I know if the source pict format is RGB24, the mask will do multiply each color. For example Red*alpha, Green*alpha, Blue*alpha. 
	If the source pict format is ARGB32, how the calculate comes on?

And what's the difference between Composite and CompositeCA?



Thanks,
Frank

-----Original Message-----
From: Huang, FrankR 
Sent: 2010年5月21日 15:52
To: 'Jonathan Morton'
Cc: xorg-devel at lists.x.org; gtk-list at gnome.org
Subject: RE: GTK progressbar call on XRenderComposite

Ok. The test is huge for the format. The whole format number(nformats) is 16, that includes a8r8g8b8,x8r8g8b8,a8,r5g6b5...x2b10g10r10. I think your suggest's format is used often. So I will point these format to tests. And maybe use one color. And test blend,composite,cacompoiste with Src(Dst,Over,Clear)...
I'll go on:)


Thanks,
Frank

-----Original Message-----
From: Jonathan Morton [mailto:jonathan.morton at movial.com] 
Sent: 2010年5月21日 14:59
To: Huang, FrankR
Cc: xorg-devel at lists.x.org; gtk-list at gnome.org
Subject: RE: GTK progressbar call on XRenderComposite

On Fri, 2010-05-21 at 14:28 +0800, Huang, FrankR wrote:
> I decided to use rendercheck application to correct the rendering
> error in Geode drivers.  With this miscellaneous app, I will test
> every operation, every pict format. 
> Use -o and -t option to minimize what I want.
> Do you know the -f option use?

I would test a8r8g8b8 first, then add x8r8g8b8, a8 and r5g6b5 to the
list.  Probably once you fix the logic for those, the rest should follow
naturally.

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






More information about the xorg-devel mailing list