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. STEPS TO REPRODUCE: Load http://www.fas.harvard.edu/~dbaron/css/test/results ACTUAL RESULTS: Takes 60 seconds to load. EXPECTED RESULTS: The fastest layout on the planet :-) DOES NOT WORK CORRECTLY ON: * Linux, apprunner, 1999-09-24-08-M11 * Linux, viewer, 1999-09-26-08-M11 ADDITIONAL INFORMATION: 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.

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?

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...

Putting on [Perf] radar

On the page http://www.fas.harvard.edu/~dbaron/links/Internet , 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 bugs...

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.

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?

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. - http://www.w3.org/TR/REC-CSS1#font-matching 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). - http://www.w3.org/TR/REC-CSS2/fonts.html#algorithm 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?

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.

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.

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.

Here is an example where the same symptoms occur with a recent Win32 build. The site is http://www.voodooextreme.com. 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. STEPS TO REPRODUCE: Load http://www.voodooextreme.com 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.

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 rickg@netscape.com so that it has some chance of being addressed.

skoll@pacbell.net, 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.

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.

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

Moving all of my M15s to M16. Please add comments if you disagree.

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 <haible@ilog.fr> 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 unoptimized. 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. Bruno New files: xc/include/extensions/xf86bigfstr.h xc/include/extensions/xf86bigfont.h xc/programs/Xserver/Xext/xf86bigfont.c Modified files: xc/config/cf/xfree86.cf xc/include/extensions/Imakefile xc/lib/X11/Font.c xc/lib/X11/Imakefile xc/lib/X11/Xlibint.h xc/programs/Xserver/Xext/Imakefile xc/programs/Xserver/dix/dixfonts.c xc/programs/Xserver/hw/xfree86/common/xf86Events.c xc/programs/Xserver/mi/miinitext.c

From: Bruno Haible <haible@ilog.fr> I don't think the bug you mentioned [1] will profit a lot from the extension: 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. Bruno [1] http://bugzilla.mozilla.org/show_bug.cgi?id=14961

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?)

From: Juliusz Chroboczek <jec@dcs.ed.ac.uk> To: fonts@XFree86.Org EvdP> http://bugzilla.mozilla.org/show_bug.cgi?id=14961 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 metrics. 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. Sincerely, J.

> (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.

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

http://www.linux.com/ 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 "http://www.linux.com/" 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). /usr/openwin/lib/X11/fonts/F3/,/usr/openwin/lib/X11/fonts/F3bitmaps/,/usr/open win/lib/X11/fonts/Type1/,/usr/openwin/lib/X11/fonts/Speedo/,/usr/openwin/lib/X11 /fonts/misc/,/usr/openwin/lib/X11/fonts/75dpi/,/usr/openwin/lib/X11/fonts/100dpi /

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

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...

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: http://www.fas.harvard.edu/~dbaron/links/Internet 10 sec. http://www.fas.harvard.edu/~dbaron/css/test/results 11 sec. System: P120 running Linux RH6. 36k modem connection. (With a 56k modem). Located in Norway.

Same configuration, testing with Mozilla nightly build ID 2000-040109 http://www.fas.harvard.edu/~dbaron/css/test/results 25 sec.

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.

Marking verified won't fix per last comments.