[Xorg-driver-geode] Glyph rendering

[Huang, FrankR]

Mart,

	What is the libXrender function is used when run "x11perf -a10text"?
	Is it XRenderCompositeString8? Or a xft library function?
	If we find a simple application to do the glyph rendering which is much like the XrenderComposite(rendercheck), it is more easy to find any clue.

Thanks,
Frank

-----Original Message-----
From: xorg-driver-geode-bounces+frankr.huang=amd.com at lists.x.org [mailto:xorg-driver-geode-bounces+frankr.huang=amd.com at lists.x.org] On Behalf Of Mart Raudsepp
Sent: 2010年7月16日 0:29
To: Michel Dänzer
Cc: Huang, FrankR; xorg-driver-geode at lists.x.org; Jonathan Morton
Subject: Re: [Xorg-driver-geode] Glyph rendering

On N, 2010-07-15 at 18:23 +0200, Michel Dänzer wrote:
> On Don, 2010-07-15 at 19:15 +0300, Mart Raudsepp wrote: 
> > Hello,
> > 
> > On N, 2010-07-15 at 17:59 +0200, Michel Dänzer wrote:
> > > On Don, 2010-07-15 at 14:13 +0300, Mart Raudsepp wrote: 
> > > > On N, 2010-07-15 at 17:35 +0800, Huang, FrankR wrote:
> > > > > Jonathan,
> > > > > 
> > > > > 	That's Mart's findings. I am not sure if he got it from debug or from code.
> > > > > 	From my debug, only three rendering requests for "x11perf -aa10text" are met in lx_check_composite. That three requests are still:
> > > > > 	1)Op:PictOpAdd, Src:PICT_a8r8g8b8 Mask:0 Dest:PICT_a8
> > > > 
> > > > 
> > > > I got it from code and Michel. The source is just a pointer at the code
> > > > I was looking at, and I didn't track that all the way down to its
> > > > creation, as Michel said that source should commonly be PICT_a8 there.
> > > > 
> > > > The first checks destination is definitely PICT_a8 on first try.
> > > > 
> > > > The source to CheckComposite call comes from exaGlyphs second argument,
> > > > which seems to be the src PICTURE passed from CompositeGlyphs{8,16,32}.
> > > > This appears to be the 1x1 pixel with repeat set solid color...
> > > > Why would we try to PictOpAdd that solid color to a PICT_a8 glyph alpha
> > > > masks cache to decide if glyph mask copy to glyph cache is possible?
> > > > Later the PictOpAdd operation is done with buffer->mask as the source
> > > > instead..
> > > > 
> > > > Is my analysis correct and there's a bug like that in Xserver commit
> > > > 346e7152?
> > > 
> > > Yeah. :( Probably best just to revert that commit, given it was intended
> > > to help you guys but failed quite spectacularly at that...
> > 
> > Probably. Would probably take quite should reshuffling otherwise to work
> > as intended, as the buffer pointer is gotten much later on.
> > 
> > 
> > But this means we'll have to add Src:PICT_a8r8g8b8 Mask:0 Dest:PICT_a8
> > PictOpAdd acceleration support still at rather high priority to be fast
> > in existing out-the-door xorg-server-1.6/1.7/1.8 releases.
> 
> Actually, you just need to 'accept' this case in the CheckComposite
> hook, you can still reject it in PrepareComposite.

Ah, yes, good point :)
Hopefully this kind of operation doesn't get used often in non-glyph
rendering.

So we can start with accepting in lx_check_composite and then reject in
lx_prepare_composite. I can write a patch for that soon then, then we
can develop and test with xserver released versions still.
I guess it could be direct reject in CheckComposite if server is >=1.9
(and the revert gets backported into that), but probably not worth the
temporary complication.


Do you need anything from me for the xserver commit revert and can we
shoehorn that onto 1.9 (and possibly 1.8) branches? :)


Regards,
Mart Raudsepp

_______________________________________________
Xorg-driver-geode mailing list
Xorg-driver-geode at lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-geode