[PATCH] (Draft2) Make X11 server-side fonts and Mule suck less.

[stephen at xemacs.org]

Aidan Kehoe writes:

 > It can avoid the ?entirely inappropriate pattern for the given charset? 
 > aspect, and that is important. Remember that the existing API says nothing
 > about _where_ the charset-registry pattern matches;

If you say so; I thought that it was matched appropriately for an XLFD
(maybe that's just wishful thinking, though).  It shouldn't be too
hard to arrange that, since a sane server will return only
fully-qualifed XLFDs if it returns XLFDs at all, and what are we
supposed to do about insane servers, anyway?!

 > "courier" is an appropriate value for it. 

This is quantitatively important?  Where does the charset registry
pattern "courier" occur?

 > Agreed, I don?t propose backporting anything to 21.4. But my understanding
 > is that the cache works; the performance problems are a result of the design
 > being heinous, not any implementation bug. What makes you think the cache
 > doesn?t work, if that is your understanding? 

XListFonts is being called more than once per font, as I understand
it.  That need not and should not happen.  It probably shouldn't
happen more than once per session, unless the user explicitly requests
it.  (The cache should be invalidated only when the user adds fonts,
but at first blush seems unlikely that that would happen without the
user knowing about it.)

(Of course this is terrible design today, when XListFonts might return
10000 fonts taking up a couple MB of memory, and then get converted to
a list of Lisp strings taking up even more.  But it would be better
than the current behavior for almost everybody---user seconds are more
expensive than MB in almost all cases.)