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:[email protected]]
Sent: 2010?7?21? 0:41
To: Huang, FrankR
Cc: Deucher, Alexander; Writer, Tim; Mart Raudsepp; Torres, Rigo;
[email protected]; [email protected]; Cui, Hunk
Subject: Re: Glyph rendering
On Mon, Jul 19, 2010 at 4:05 AM, Huang, FrankR <[email protected]> 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
>
>
> _______________________________________________
> [email protected]: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
