page takes 60 seconds to load due to Unix font loading




19 years ago
14 years ago


(Reporter: dbaron, Assigned: erik)




Firefox Tracking Flags

(Not tracked)




(2 attachments)

DESCRIPTION:  The above URL takes about 60 seconds to load on my machine
(details below).  The first 45 seconds of this have near-100% CPU usage.  This
seems to be a useful test case for performance testing - there's something going
wrong here.  This page does take some time to load on other browsers, but not
nearly that much.

The page has a large table that is heavily styled using CSS.


ACTUAL RESULTS:  Takes 60 seconds to load.

EXPECTED RESULTS:  The fastest layout on the planet :-)

 * Linux, apprunner, 1999-09-24-08-M11
 * Linux, viewer, 1999-09-26-08-M11

My machine is a PII-233 running RedHat Linux 6.0 (with updates), and has 64MB of
RAM and an STB Veliocity video card (I think) using the XF86_SVGA X-server.


19 years ago
Assignee: troy → kipp

Comment 1

19 years ago
Loads reasonably fast for me on Windows. We load the page and then throw
everything away and recreate all the frames (looks like when the linked style
sheet is loaded), which isn't helping performance.

Kipp, you develop on Linux. If this is a problem for you, then maybe you or
another Linux developer can take a look?

Comment 2

19 years ago
On my machine here at home it takes up to 10 seconds to load. Usually faster,
but it depends on how much of the page is loaded before we throw it all away
and recreate the frames...


19 years ago
Whiteboard: [Perf]

Comment 3

19 years ago
Putting on [Perf] radar

Comment 4

19 years ago
On the page , the horrible
performance (40-60s vs. 5s) seems to be due to the use of the “ and
” entities.  The problem could be the same here, except Troy reports 10s
on NT (does that include network loading?), so there are probably some other XP
issues that could be addressed.  I also don't know if the font performance
should really be that bad (it also could be specific to xfsft vs. xfstt,
although xfsft, which I use, supposedly does a better job with font caching, if
I'm not getting things backwards).  This should probably be split into two

Comment 5

19 years ago
It takes both gfontsel and xfontsel about 30 seconds to load
-*-bitstream cyberbit-*-*-*-*-*-*-*-*-*-*-iso10646-1 for the first time, and
less thereafter.  This is likely the problem.  I wonder if there is any way
around this.  I use xfsft, and I added the iso10646-1 encoding manually.

Comment 6

19 years ago
When the font-family list ends with a generic font, I believe the implementation
is supposed to do its best to find *some* font to satisfy the request. Our
implementation enumerates the fonts available on the system, and checks to see
if the required glyph(s) are available within those fonts. Since the Bitstream
font has been made available, it will be loaded and checked.

One possible solution might be to load iso10646-1 fonts last, hoping to find
the required glyphs in other fonts first. How does that sound?

Comment 7

19 years ago
CSS1 and CSS2 seem to suggest that you should even find a character in other
fonts not in the font-family list (including the generic), although it's not
very clear:

5. If there is no font within the family selected in 2, then use a UA-dependent
default 'font-family' and repeat step 2, using the best match that can be
obtained within the default font.


8. If there is no font within the family selected in 2, then use the inherited
or UA-dependent 'font-family' value and repeat from step 2, using the best match
that can be obtained within this font. If a particular character cannot be
displayed using this font, the UA should indicate that a character is not being
displayed (for example, using the 'missing character' glyph).


The solution of checking iso10646 fonts last seems useful.  You seem to be
caching the necessary information already (i.e., it is much faster the second
load - but I didn't try different characters).  However, are there any other,
similar, encodings that should be checked last?

Comment 8

19 years ago
Bitstream is one of the largest fonts that I know of, so iso10646-1 is clearly
a candidate for putting near the end of the list. There are no other huge
charsets, but there are some smaller ones, like the Japanese, Chinese, etc
fonts. Then again, it might be the speed of the TrueType font servers on X that
make it slow (rather than the size). I don't know. We'd probably have to do
some tests to find out what's slow.


19 years ago
Assignee: kipp → erik

Comment 9

19 years ago
Giving this to erik so that he has a bug to close when he's done the performance
work needed to the font picking logic.


19 years ago
Target Milestone: M15

Comment 10

19 years ago
I'll take a look during M14/M15. I don't know yet whether this is something we
can fix. It may have more to do with the font server and/or size of font.


19 years ago
Blocks: 17962

Comment 11

19 years ago
Here is an example where the same symptoms occur with a recent Win32 build.  The
site is  Takes at least 90 seconds to fully load,
using 100% cpu the whole while.  Other browsers (IE and NS) take 40 seconds, so
it's a slow page to begin with, but they don't use 100% cpu.


ACTUAL RESULTS:  Extremely slow load time, using 100% CPU

EXPECTED RESULTS: Load time on par with other browsers, and definitely shouldn't
pin the CPU.

VERSION TESTED: Win32 1999-12-03-02

The cause of this bug may not be the same as what is described in the above
comments, but the symptoms are, so I thought it should be filed here rather than
as a separate bug.

Comment 12

19 years ago
No, please don't add unrelated bugs to this report. This bug has been narrowed
down to font issues. Your added bug hasn't been narrowed down to font issues,
so it could well be a different issue. If you put this on my list, it may get
ignored for a while (I'm going on a 6-week sabbatical starting Dec 18). Please
create a separate bug report and assign to so that it has
some chance of being addressed.


19 years ago
Summary: page takes 60 seconds to load → page takes 60 seconds to load due to Unix font loading, please file that as a separate bug, as erik said.  This bug
is well understood, and is Unix-specific.

In general, if you're not sure if something's a duplicate, file a separate bug
and mention the possibly-related bug.  Otherwise, bugs become too difficult to
understand because of unrelated comments.

Comment 14

19 years ago
Yes yes.  My apologies.  It is now filed as bug 20485.  I make very careful
bugzilla queries to avoid filing duplicate bugs, and to add relevant info to
existing bugs, but this time my search had led me astray.

Changing the summary, like you did, should help prevent it from happening again.
Created attachment 3658 [details]
some stack traces during performance problems (on suspend) showing font loading as the problem


19 years ago
Keywords: perf

Comment 16

19 years ago
Bulk add of "perf" to new keyword field.  This will replace the [PERF] we were
using in the Status Summary field.

Comment 17

19 years ago
Moving all of my M15s to M16. Please add comments if you disagree.
Target Milestone: M15 → M16


19 years ago
Whiteboard: [Perf]

Comment 18

19 years ago
At some point, I hope to look into the following. Erik.

Subject: bigfont optimization
Date: Mon, 7 Feb 2000 16:41:33 +0100 (MET)
From: Bruno Haible <>
To: patch@XFree86.Org
CC: fonts@XFree86.Org

Here is a new version of the bigfont optimization.

Remember that big fonts suffer from the following: All clients that have
opened a font can access the complete glyph metrics array (the XFontStruct
member 'per_char') directly, without going through a macro. Moreover these
glyph metrics are ink metrics, i.e. are not redundant even for a fixed-width
font. For a Unicode font, the size of this array is up to 768 KB. For
the Unicode fonts already present in 3.9.17, the size varies between 120 KB
and 150 KB.

The first version of this patch, months ago, optimized only the case of
local clients, by use of shared memory, and left the remote clients

This version here also optimizes the non-local clients: the glyph metrics
are transmitted over the wire in a compressed format, which reduces the
size of the transmitted data by nearly a factor of 6 for large fonts,
and still by a factor of 2 for small 8-bit fonts. The compression is fast
(O(N) where N is the size of the uncompressed data).

Care has been taken for interoperability with older/other X11 vesions:
A client with an older libX11 obtains the uncompressed data via the socket,
unchanged. Newer clients with an older X server will notice the X server
doesn't understand the XF86BIGFONT extension and will fall back on the
old mechanism.

I've been running this patch for 4 weeks now, without problems. But in the
- unexpected - case that the extension causes problems to someone, it can
be disabled by setting the XF86BIGFONT_DISABLE variable to 1.


New files:

Modified files:

Comment 19

19 years ago
From: Bruno Haible <>

I don't think the bug you mentioned [1] will profit a lot from the

The user saw the X server busy for 60 seconds. If only one font is involved,
then gunzipping the file and rendering the truetype font is certainly much
more costly than filling 768 KB of memory and piping it to a client. If
more than one font is accessed -- you can "see" which fonts have been
accessed by the X server by simply doing an "ls -lrtu
/usr/X11R6/lib/X11/fonts/..." after the operation -- then the way to solve
the problem is to touch less fonts, i.e. to give more precise wildcards
in the XLFD.


I think that, when this happens, it's generally a case where the character is
not in any of the available fonts, so one must check all the fonts with a
character encoding that could contain the character.  (However, are you sure you
never check fonts that are in an encoding that couldn't have the character?)

Comment 21

19 years ago
From: Juliusz Chroboczek <>
To: fonts@XFree86.Org


No, Erik.  The problem you see here is different.

The X protocol specifies that font metrics should be made available to
the server at font open time.  This means that the TrueType backend
needs to rasterise all glyphs at font open time just to determine the

There is currently only one workaround: the TrueType backend optimises
the special case of charcell fonts (this was implemented with CJK
users in mind).  I suggest your users avoid humonguous proportional
fonts such as Cyberbit.



Comment 22

19 years ago
> (However, are you sure you
> never check fonts that are in an encoding that couldn't have the character?)

The code looks at the encodings indicated by XListFonts(). It will not actually
*load* any font that is known not to contain the right glyph. However, for
*-iso10646-1 fonts, it is impossible to tell which glyphs are contained without
loading the font. Maybe I should make sure that *-iso10646-1 fonts are used as
a last resort (i.e. try them last, after all the other encodings). See the
TryFamily() function.

Comment 23

19 years ago
*** Bug 28772 has been marked as a duplicate of this bug. ***

Comment 24

19 years ago runs quite slow due to font querying on Unix.
Timing performed with a 3/2 morning cvs pull compiled with
--disable-debug --enable-optimize --enable-x11-shm.  The test machine
was a Sun Ultra-10 (440Mhz/afb) running Solaris 2.7.  viewer was
started with "about:blank", then "" typed into
the url entry box.

                start   end     elapsed
viewer           0:02    0:03   0:01
Xsun            96:57   97:26   0:29
wall time                       0:36

Examining an xscope log of a similar session, I see three groups
of continuous ListFontsWithInfo calls amounting for about 28 seconds
worth of load time.

start load ~ 29.56s
ListFontsWithInfo       30.51-31.42     ~15 calls
ListFontsWithInfo       31.72-57.15     ~180 calls
ListFontsWithInfo       58.25-59.97     ~12 calls
finish load ~ 67.46s

I'm running with the default font path for solaris (see below).
The output of "xlsfonts" will be attached to this bug.  xscope
log available on request (1.2 Mb).


Comment 25

19 years ago
Created attachment 6012 [details]
xlsfonts from solaris-2.7

Comment 26

19 years ago
Created new bug 30160 for XListFontsWithInfo problem. That call is far too
expensive and must be removed from Mozilla.

Comment 27

19 years ago
How often is this problem encountered? I'm leaving the target as M16 for now,
though I *really* don't know what to do about this, other than some hacks...

Comment 28

19 years ago
Just for fun i loaded the "problem" URL's in Netscape Communicator 4.7. Cached
files were deleted and Netscape 4.7 started afresh.
Got these times on complete loads: 10 sec. 11 sec.

System: P120 running Linux RH6. 36k modem connection. (With a 56k modem).
Located in Norway.

Comment 29

19 years ago
Same configuration, testing with Mozilla nightly build ID 2000-040109 25 sec.

Comment 30

19 years ago
I don't think it's a good idea to put hacks into Mozilla to try to work around
the problem with large TrueType fonts taking a long time to load. We will
probably have to tell users to avoid installing such large fonts, or to get a
faster TrueType server. Also, I don't want to treat *-iso10646-1 fonts specially
since there are some small ones that load fast and look nice in newer versions
of XFree86 (based on Adobe's original contribution, etc). Marking WONTFIX.
Last Resolved: 19 years ago
Resolution: --- → WONTFIX

Comment 31

19 years ago
Marking verified won't fix per last comments.
You need to log in before you can comment on or make changes to this bug.