[Xorg-driver-geode] Glyph rendering

[Mart Raudsepp]

On R, 2010-07-16 at 16:59 +0800, Huang, FrankR wrote:
> 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.

It seems to be XRenderCompositeString8, but going through xft library
(xft library calls XRenderCompositeString8).
That's what is doing the actual rendering. Before that glyphsets are
declared and uploaded, I believe.

We just basically need to get this operation from exaGlyphsToMask
accelerated:

    exaCompositeRects(PictOpAdd, buffer->mask, NULL, pMask,
                      buffer->count, buffer->rects);

Source is going to be PICT_a8 with normal anti-aliasing (no subpixel
smoothing), and destination is also of PICT_a8 format. Don't be confused
by the naming of the variable (pMask), it's passed as the destination
and mask is NULL. exaCompositeRects prototype is (op, src, mask,
dst, ...)
Once we hack the driver to workaround the bug in xserver, that is.
Before we do that, you are seeing the destination as PICT_a8r8g8b8, and
we don't care about that case at first.
Once the workaround Michel proposed is applied, your previously curious

2)Op:PictOpAdd, Src:PICT_a8 Mask:0 Dest:PICT_a8r8g8b8

starts to be

Op:PictOpAdd, Src:PICT_a8 Mask:0 Dest:PICT_a8
instead


If you have bugs in non-corner cases in the acceleration code you write,
you should see corrupted text.


Regards,
Mart Raudsepp

> 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
> _______________________________________________
> Xorg-driver-geode mailing list
> Xorg-driver-geode at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-geode