Glyph rendering

[Huang, FrankR]

Alex,

	Yes. I have given up using that way. It is not correct because of the splitting bits of 3,3,2.
	I am trying to use ARGB to play a trick to do the PICT_a8 add. From the debug, the memory space add value is right. But the final result is not correct.
	Then I wrote a function to do the PICT_a8 add operation( MAX(x+y, 255)), the result is right. And the performance has grown up to 23700/s. It is same as using "NoAccel" way:).


Thanks,
Frank

-----Original Message-----
From: Alex Deucher [mailto:alexdeucher at gmail.com] 
Sent: 2010?7?21? 0:41
To: Huang, FrankR
Cc: Deucher, Alexander; Writer, Tim; Mart Raudsepp; Torres, Rigo; xorg-devel at lists.x.org; xorg-driver-geode at lists.x.org; Cui, Hunk
Subject: Re: Glyph rendering

On Mon, Jul 19, 2010 at 4:05 AM, Huang, FrankR <FrankR.Huang at amd.com> wrote:
> Alex,
>
>        So long mail.
>        I put the feedback here.
>        1)For the repeat, I have debug the code that our driver's repeatType is RepeatNormal. And we should add the code to fallback when it is RepeatPad or RepeatReflect.
>        2)For the transformPoint, our geode has the same code you copy. :)
>
>        Another question to ask:
>        For the glyph rendering, we have found a bug in EXA when it gives the parameter to our DoComposite function. Actually, the op we need handle are following two ops:
>        1)PictOpAdd, src: PICT_a8, mask: 0, dst: PICT_a8
>        2)PictOpOver, src: PICT_a8r8g8b8, mask: PICT_a8, dst: PICT_r5g6b5
>        Our driver has support the 2) operation. But for the 1) operation, we know it is very easy, but unfortunely our dest format in HW can not be PICT_a8, it can only be PICT_r3g3b2 for 8bits in geode. Do you know this format?
>        Another method is that we can do a copy from PICT_a8 to PICT_a8r8g8b8 and do a PictOpAdd?
>        The worst is I wrote a function to do every pixel PictOpAdd in a while loop.
>        What do you think?

332 formats are 3 bits for R, 3 bits for B, and 2 bits for G.  I don't
think using 332 will work in this case.  You'd probably have to
fallback for that one or copy to an 8888 format first.

Alex

>
> Thanks,
> Frank
>
>
> _______________________________________________
> 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
>