Closed Bug 34242 Opened 24 years ago Closed 23 years ago

X font lookups on -*-*-*-*-*-*-*-*-*-*-*-*-*-*

Categories

(Core :: Layout, defect, P3)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla0.9.7

People

(Reporter: tenthumbs, Assigned: shanjian)

References

Details

(Keywords: fonts, perf)

Attachments

(1 file, 1 obsolete file)

I was looking through X font handling code and came upon the gtkfotnsel package
which had a very interesting comment that some X servers will add extra font
names to a reply to XListFonts (-*-*-*-*-*-*-*-*-*-*-*-*-*-*)  rather than to
XlistFonts (-*). This is true for Linux and XFree86.

On my machine  xlsfonts -fn '-*-*-*-*-*-*-*-*-*-*-*-*-*-*' returns 2623 lines
but xlsfonts -fn '-*' return 1777. Most, if not all, of the extra lines seem to
be partially qualified forms of scalable fonts; i.e., it's replacing some of the
'0's. More important, the second form is significantly faster.

This suggests that a patch like:

Index: mozilla/gfx/src/gtk/nsFontMetricsGTK.cpp
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/gtk/nsFontMetricsGTK.cpp,v
retrieving revision 1.81
diff -u -r1.81 nsFontMetricsGTK.cpp
--- mozilla/gfx/src/gtk/nsFontMetricsGTK.cpp    2000/03/27 00:10:29     1.81
+++ mozilla/gfx/src/gtk/nsFontMetricsGTK.cpp    2000/04/02 16:02:48
@@ -2596,7 +2596,7 @@
    */
   if (!gGotAllFontNames) {
     gGotAllFontNames = 1;
-    GetFontNames("-*-*-*-*-*-*-*-*-*-*-*-*-*-*");
+    GetFontNames("-*");
   }
 
   PL_HashTableEnumerateEntries(gFamilies, SearchFamily, &search);
@@ -2642,7 +2642,7 @@
 
   if (!gGotAllFontNames) {
     gGotAllFontNames = 1;
-    GetFontNames("-*-*-*-*-*-*-*-*-*-*-*-*-*-*");
+    GetFontNames("-*");
   }
 
   return 1;

may be a performance win.

However, trimming all the other wildcard strings to their shortest values may
not be a good idea because at leat one font server, xfstt, has trouble with a
string like '-*-arial-*' as opposed to '-*-arial-*-*-*-*-*-*-*-*-*-*-*-*'.

I suppose this is some kind of X feature but I have no idea what that is.
Erik, I don't know if this is you or Pav
Assignee: troy → erik
Hopefully I will have time to look into this soon after Feature Complete (M16).
Thanks for the investigation and report.
Status: NEW → ASSIGNED
Target Milestone: --- → M17
reassign to bstell. please take a look at this and talk to erik 
Assignee: erik → bstell
Status: ASSIGNED → NEW
Target Milestone: M17 → M24
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Short test on Solaris 7 SPARC:
-- snip --
% xlsfonts -fn '-*-*-*-*-*-*-*-*-*-*-*-*-*-*' | wc -l
    7381
% xlsfonts -fn '-*' | wc -l
    6336
-- snip --
It looks that this issue applies to Solaris, too...

Also interesting is
  time xlsfonts -fn '-*-*-*-*-*-*-*-*-*-*-*-*-*-*' >/dev/null
and
  time xlsfonts -fn '-*' >/dev/null
On my Linux system I see about a 10% speed improvment in xlsfonts.
On my Linux I see a factor of 2. I suspect it has a lot to do with the
fontpath and how it's managed. My system follows the generic XFree86
pattern with the X server itself handling the bitmap fonts and the type1
fonts that come with XFree86. Font server(s) handle everything else. Are
you running Redhat? Maybe their hacked-up font server is doing something
odd.
I'm running Redhat 6.2
so... this may improve performance but may have some risk. move to moz0.9.3 
which mean we can work on it be it is not critical for moz0.9.2
Priority: P3 → P2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
I think the xlsfonts tests will show if there's a risk on any particular Unix
platform.

I have heard that HP-UX is particularly slow in font handling. If this
works, it could be a big win.
(personally, I don't have strong opinions about making the proposed fix or no.)

Shanjian: can you try timing the xlsfonts code on HP-UX so we can determine
the affect there?

Not surprisingly, I think that any win is a win, provided it doesn't break on
any of the Unix platforms.
too risky now. mark it future.
Target Milestone: mozilla0.9.3 → Future
ftang:
Please define "too risky"...
... I don't see much risk here... only some testing is required...
performance work. consider for m94
Keywords: perf
Target Milestone: Future → ---
BTW, every one of the extra XLFD names generated appears to be a bitmap font. A
whole lot of bogus entries can't be good.
move to m94. 
Target Milestone: --- → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Keywords: fonts
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 103179
shanjian-
bstell is busy right now. Do you have a linux build? Can you look into this one? 
1. we need to make sure such change won't cause some font didn't get reported.
It is ok if reduce duplicate report font name. It is NOT ok if the one got
remove is not dupblicate
2. we need to measure the performance win. Will it really make it faster? will
it impact the startup performance. 
Assignee: bstell → shanjian
Status: ASSIGNED → NEW
P3
Priority: P2 → P3
accepting.
Status: NEW → ASSIGNED
I did some testing on HPUX. Present version take 44 ticks, and the new one take 
only 31. xlsfonts on HPUX shows all those fonts are in partially qualified forms 
(0 in second to last value). 
the possible risk of this bug is that we might lose some fonts in certain X 
platform. Fix for 90813 might reduce the risk of possible side-effect. I would 
like to check it in after 90813. 
Depends on: 90813
Target Milestone: mozilla0.9.6 → mozilla0.9.7
No longer depends on: 90813
Some extra performance data:

>xlsfonts -fn '-*' | wc -l
1817
>xlsfonts -fn '-*-*-*-*-*-*-*-*-*-*-*-*-*-*' | wc -l
2839

>time xlsfonts -fn '-*-*-*-*-*-*-*-*-*-*-*-*-*-*' > /tmp/full
real    0m0.240s (average)
>time xlsfonts -fn '-*' >/dev/null
real    0m0.080s (average)

Speed Increase : 200%

System:
Slackware Linux 2.2.16 (Pentium II 350 MHz)
XFree86 4.1.0 (modules freetype + type1 + speedo)

Most fonts are TrueType, installed on a rather slow Fat32 disk.
With both commands I got the same font list except for variations in point size,
pixel size, resolution and width.
I'd like to see the performace of a Solaris 8 system with _all_ locales
installed (which means a _LOT_ of fonts installed) running either en_US.UTF-8 or
(better) ja.UTF_8...
... can someone provide such data ?
Attached patch patch (obsolete) — Splinter Review
Comment on attachment 58543 [details] [diff] [review]
patch

I'll file another patch incl. changes for Xlib toolkit ...
Attachment #58543 - Flags: needs-work+
My biggest concern to this bug is that we might miss some fonts in certain 
system. If only those partially qualified form are missed, we should be OK. 
Linux, Solaris, HPUX have been verified. Let's take a look at True64 and SGI. 

CC to jdunn
I suggest a comment in the code referencing this bug so future people will know
what it's all about.
shanjian:
Wanna request r=/sr= for the patch, please ?
Keywords: patch, review
Comment on attachment 58547 [details] [diff] [review]
Patch for Xlib and GTK+ gfx incl. comment with reference to this bug

r=shanjian
Attachment #58547 - Flags: review+
Now it might be the right time to give it a try. 

blizzard, could you sr? 
brendan, 
blizzard told me that he can't sr this bug at this moment. Could you take a look 
instead? thanks.
Comment on attachment 58547 [details] [diff] [review]
Patch for Xlib and GTK+ gfx incl. comment with reference to this bug

sr=brendan@mozilla.org
Attachment #58547 - Flags: superreview+
fix checked in. 
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: