XQueryFont() in nxclient and KDE (with hints on how to improve)

Kurt Pfeifle k1pfeifle at gmx.net
Fri Jul 1 15:31:42 CEST 2005


On Friday 01 July 2005 09:17, Lars Knoll wrote:
> On Friday 01 July 2005 03:15, Kurt Pfeifle wrote:
> > Hi,
> >
> > some of you may have seen in person demos of the latest NX and FreeNX
> > releases or snapshots at LinuxTag.
> >
> > Some may have discussed with Gian Filippo Pinzari NX related stuff.
> >
> > After the event we had some private mail exchange. Here is an important
> > tidbid he had to say in retrospective:
> > 
> > > Somebody asked if we have suggestions to give to the KDE developers to
> > > improve the network performances of their desktop. For the KDE people
> > > who are listening:
> > >
> > > A KDE startup on a SuSE 9.2 makes a single XQueryFont() (that sums up
> > > to the single XQueryFont() made by nxagent to initialize its font cache
> > > at startup). So far so good, but then KDE tries to install some applica-
> > > tions in the system tray. Given that these application are -really-
> > > useful and that they -really- need to be started by default, these
> > > programs make alone 40 XQueryFont() and take, to startup, nearly 40
> > > seconds on a modem. Without these programs, the whole session wouldn't
> > > have taken more than 10 seconds. Furthermore, until these programs are
> > > loaded, the K menu and the desktop are not responding to the user input.
> > >
> > > /Gian Filippo.
> >
> > I do not know how to fix it properly.
> >
> > But one or more of you guys may be interested to take a look at that
> > corner....
> 
> With Qt 3.3.x you should not get a single XQueryFont if you have Xft, as we 
> are in this case not using server side fonts at all. You might want to debug 
> where these calls come from first.
> 
> Cheers,
> Lars

Gian Filippo updated his findings:

<quote>
   I checked again. Actually the count of requests is:
   
      - X_QueryFont, opcode 47, in number of 2.
   
      - X_ListFonts, opcode 49, in number of 40.
   
   So the title would better read XListFonts(), etc.
   
   After starting KDE, running the nxclient --dialog takes:
   
      - X_QueryFont, opcode 47, in number of 1.
   
      - X_ListFonts, opcode 49, in number of 2.
    
   I repeated the same test by only running nxclient --dialog,
   without starting the KDE session first:
   
      - X_QueryFont, opcode 47, in number of 2.
   
      - X_ListFonts, opcode 49, in number of 2.
   
   This means that I was wrong about nxclient, that is rather very
   good, at least at this. Doing only 4 queries is not that bad, after
   all. Hope this is the result of some hard work, and not just luck.
   The one to blame was only the unknown KDE application hooking it-
   self in the system tray.
   
   A technical annotation about nxclient: it seems that it is query-
   ing only one out of the 2 fonts queried by KDE. Given they end up
   using the same fonts, it looks to me that they should query exact-
   ly the same fonts. This is very minor, so take it for what it's
   worth.
</quote>

Note that there is still a performance problem for KDE to be tracked down.
the "minor" rating is in relation to nxclient, which also was amongst the
suspects at first.


> > I'll add another quote (which may be of interest to everyone developing
> >
> > an NX client or the nxclientlib/nxc:
> > > For the nxclient developers:
> > >
> > > There is no need at all to query the X core fonts when Xft is avail-
> > > able, or when the default system font (that is anti-aliased) is found.
> > > When a font is Xft-enabled, Xft uses RENDER to load and display the
> > > glyphs, so there is no need to "query" it.
> > >
> > > These unneeded XQueryFont() requests are very annoying. nxagent caches
> > > the XQueryFont() replies but can't avoid the first request for a font
> > > that was not queried already. This basically explains why, the first
> > > time, starting nxclient inside a NX session takes so long.
> >
> > Cheers,
> > Kurt

Cheers,
Kurt


More information about the Kde-optimize mailing list