libXrender - documentation?

Charles Lindsey chl at clerew.man.ac.uk
Wed Jan 28 06:26:41 PST 2009


In <194f62550901261140q12d1ed46k9075ebcc83deaf0a at mail.gmail.com> Clemens Eisserer <linuxhippy at gmail.com> writes:

>> I can't see any such calls of XRender* functions in the bits of xft that I
>> have been looking at (notably in xftcore.c).
>Because xft deals with Glyphs, and for performance/bandwith resons
>glyphs are handled in a special manner.
>That was what I ment with "(using the XRender*Glyphs functions)".
>xftglyphs: XRenderAddGlyphs
>xftrender: XRenderCompositeText...

OK, since you wrote that I have been poking around in the xft source, and
the situation seems to be as follows:

Libxft contains two modules (xftcore and xftrender). One does
antialiassing client-side (with much consumption of cpu resources, some of
it unnecessarily) and the other does it client side by calling
XRenderCompositeText16 and friends (and I don't know what goes on behind
those calls, because of lack of documentation thereof :-) ).

To decide which to use, libxft first calls XRenderQueryExtension to see it
the server is willing, and then calls XRenderFindVisualFormat to see
whether the visual is suitable, and then calls XRenderFindFormat to see
whether the particular font is capable. If any of those fails, it falls
back to xftcore.

Now I am using Solaris-10 as my operating system, and libXrender and
libxft come bundled with it, and its documentation proudly proclaims

   "This feature [the XRender Extension] is included in the Solaris 10
   3/05 release" (and it was actually in Solaris-9 before that).

So I poked around using truss and the Debug facility in libxft, and
discovered that the Opera/QT/Solaris combination always took the xftcore
route. Finally, in desperation, I tried 'xdpyinfo -ext RENDER' and it told
me:

      RENDER extension not supported by server

Aaaaaaaarrrrrrrrrgggggggggggghhhhhhhhhh!

So it is evidently a SUN problem, and I shall pursue it in that quarter.
In the meantime, I apologise for impugning the ability of libxft to do
antialiassing properly when presented with the proper environment.

>>>However as far as I know xft already has a XRender aware backend
>>>(using the XRender*Glyphs functions), as well as legacy support for
>>>pre-xrender servers.

Yes, I can now see that is the case.

>> But who is actually responsible for the development/maintenance of xft?
>> For sure they do not seem to hang around on this list, though I gather
>> they are within the overall Xorg structure somewhere.
>XFT is more or less a sample implementation, and as far as I know its
>not used a lot.

Well, apart from QT (possibly older versions), it is certainly used by
Adobe in the freely available 'acroread', and I think that would count as
"a lot".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5



More information about the xorg mailing list