User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140717120014 Steps to reproduce: Visit http://dlmf.nist.gov/10.22 Actual results: took > 60 seconds to render the page Expected results: should have taken <5 seconds, as did Firefox 25.

After looking at many forum discussions about slowness, I tried several things: factory reset, safe mode, hardware accelleration on/off, disabling cairo, disabling javascript. None made any significant difference. I'm not sure if this started in release 27 or 28; it's still there in 30. I'm assuming MathML is a relevant component here: While Firefox 28 _may_ be somewhat slower than 25, in general (I didn't benchmark anything), it is _dramatically_ slower on pages with significant MathML content (such as the above URL).

I doubt if this is relevant, but even with javascript disabled, I see this message in the console, upon startup: mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create Preferences.jsm:378

I'm adding a dependency on bug 1009582 here, although the cause seems older. Can you try http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ and say at which version this started precisely...

It appears to have slowed down significantly already in the 1st beta (28.0b1) whereas the last minor release of 27 (27.0.1) is fine (although it was released later than 28.0b1, obviously without some of the latest experimentation! :> ). Hope that helps narrow it down.

(In reply to Bruce Miller from comment #4) > It appears to have slowed down significantly already in the 1st beta > (28.0b1) whereas > the last minor release of 27 (27.0.1) is fine (although it was released > later than 28.0b1, > obviously without some of the latest experimentation! :> ). Hope that helps > narrow it down. OK, thanks. The MathML bugs for Gecko 28 are: https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&query_format=advanced&component=MathML&product=Core&target_milestone=mozilla28&list_id=10819697 Possible candidates can be: - bug 114365 (mathvariant). Especially because we do some stuff to keep track of what to apply to token elements and transform the characters in the text run. - bug 415413 (intrinsic width). As I recall, there was a comment in the code that measuring the ink metrics is less efficient than using the advance width. Moreover, there is additional work to sum up individual width of text inside token elements. So we will need to narrow that down a bit more...

@Bruce: Can you please try to do https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/? According to https://wiki.mozilla.org/RapidRelease/Calendar#Past_branch_dates, you should do mozregression --good 2013-10-28 --bad 2014-03-18

I'd be happy to try it, but there are no instructions for fedora; the github installation instructions are a long chain of "you need this or that; you might need to do this; maybe that....". Apparently what I cloned from github doesn't run standalone...

Mmh, I guess one of "easy_install mozregression" or "pip install mozregression" should work as long as you have the corresponding Python env. The first worked for me.

You're right; it was an "easy install"... it's just the instructions made it seem like it would be hard! (hmm... why does that sound familiar?!?!)... OK, installed and will start the search shortly.

My, what an unpleasant program (mozregression); *very* slow server & mozregression kept timing out (I guess?) Ultimately, I ended up doing the bisection essentially by hand, running mozregression 4 times. But in the end, I narrowed it down: 2013-12-02 good 2013-12-03 bad

Thanks, so apparently, the regression is due to bug 114365 (mathvariant support): http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-12-02&enddate=2013-12-03

TO REMEMBER: do https://wiki.mozilla.org/Buildbot/Talos#Adding_a_new_test I see that the page load is a bit slow, but definitely always <5 seconds for me so I can not really confirm the bug. I've submitted a patch to the try server that disables the whole MathMLTextRunFactory (and thus breaks mathvariant support) just to see whether the issue comes from that: https://tbpl.mozilla.org/?tree=Try&rev=02b53e76ff58 @Bruce: could you try https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/fred.wang@free.fr-02b53e76ff58 when the builds are ready (hopefully before the day wakes up in the USA!). With the mathvariant support: - We now map the mathvariant attributes to CSS style (should be efficient?) - nsMathMLTokenFrame::MarkTextFramesAsTokenMathML now checks the content of each mi token frame to determine if it has only one char, and adds a frame bit if necessary. (should be relatively efficient?) - When mathvariant is specified or when we have a single char mi, a MathMLTextRunFactory object is created and used to generate a new text run and do some remapping. (should be the problem if we does that too many times?) The most frequent cases in the document seem to be 1) Italic single <mi> like <mi>x</mi> 2) Single char letters with mathvariant="normal" like <mi mathvariant="normal">∞</mi> 3) Single char <mi> with explicit mathvariant like <mi mathvariant="fraktur">A</mi> I believe the creation of MathMLTextRunFactory can just be avoided in 2). More generally, I think MathMLTextRunFactory can be avoided in some cases in 1) and 3): we could just check whether the char is potentially "remappable" (that is a-z, A-Z, Arabic letters + a few exceptions like dotless i/j) and otherwise don't set anyMathMLStyling = true. Then LaTeXML (and others) could just generate the remapped char instead of using mathvariant in order to avoid the useless calls to MathMLTextRunFactory. Note sure that will completely solve the problem, though. BTW, I'm also concerned about the ssty remapping that was done later in bug 442637 (Gecko 29), since that now almost always create a MathMLTextRunFactory.

MathMLTextRunFactory::RebuildTextRun() performs three actions. 1) Fiddles with the TextRun's gfxFontStyle 2) Rebuilds the embedded text character by character with checks for mathvariant substitution 3) Actually applies the textrun changes. 1) is minor. It can be moved, providing we can find a spot that lets us modify fontstyle objects. 2) occurs every time the MathMLTextRunFactory is invoked, but I expect that this can be skipped when character transformations are not needed. 3) is largely copy/pasted from one of the existing TextRunFactories. It may be performing some unnecessary action. I'll try to run the testcase under a profiler to see if anything obvious appears.

Your hacked version loads indeed loads the page quite quickly, so the MathMLTextRunFactory seems to be where the problem comes from. Of course, as you say, broken mathvariant (for the exotic variants) reverted as well! DLMF doesn't use those variants, in large part because Firefox hadn't been supporting them. If a quick test can determine the need for remapping, that sounds like a good solution.

(In reply to Bruce Miller from comment #14) > Your hacked version loads indeed loads the page quite quickly, so the > MathMLTextRunFactory seems to be where the problem comes from. Of course, > as you say, broken mathvariant (for the exotic variants) reverted as well! > DLMF doesn't use those variants, in large part because Firefox hadn't been > supporting them. If a quick test can determine the need for remapping, that > sounds like a good solution. However, we need a remapping for implicit mathvariant="italic" with single-char variable <mi>x</mi>, which seems ubiquitous... LaTeXML could speed up that stuff by generating the plane-1 char (as well as for bold, bold-italic, and other "exotic" mathvariants) and thus eliminating any need for MathMLTextRunFactory, but we would still have the problem of missing font coverage if no Web fonts are provided (especially on mobile). But anyway, let's see how we can optimize MathMLTextRunFactory first.

This is the first stab at improving performance. RebuildTextRun() has been split up so ssty no longer triggers mathvariant code, and where possible things have been pulled outside of loops. The earlier suggestion of testing if single char mathvariant behaviour should be triggered has been applied.

Comment on attachment 8463368 [details] [diff] [review] WIP Review of attachment 8463368 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/generic/MathMLTextRunFactory.cpp @@ +287,3 @@ > // nothing to do here > return aCh; > } If you change nsTextFrame to never do the remapping when NS_MATHML_MATHVARIANT_NORMAL, I think this can be converted into an ASSERT. @@ +523,5 @@ > +{ > + if (('A' <= aCh && aCh <= 'Z') || > + ('a' <= aCh && aCh <= 'z') || > + ('0' <= aCh && aCh <= '9') || > + (GREEK_UPPER_ALPHA <= aCh && aCh <= GREEK_UPPER_OMEGA trailing space @@ +524,5 @@ > + if (('A' <= aCh && aCh <= 'Z') || > + ('a' <= aCh && aCh <= 'z') || > + ('0' <= aCh && aCh <= '9') || > + (GREEK_UPPER_ALPHA <= aCh && aCh <= GREEK_UPPER_OMEGA > + && aCh != HOLE_GREEK_UPPER_THETA) || I think the && operator should be at the end of the previous line? @@ +586,5 @@ > + > + In the event that the script size multiplier actually makes things > + larger, no change is made. > + > + If the user doesn't want this to happen, all they need to do is set "user doesn't" VS "they need" @@ +626,5 @@ > + else if (aFlags & MATH_FONT_STYLING_NORMAL) { > + fontStyle.style = NS_FONT_STYLE_NORMAL; > + fontStyle.weight = NS_FONT_WEIGHT_NORMAL; > + } > + I think the else's above should be } else { } else if { (that is, on the same line) ::: layout/generic/nsTextFrame.cpp @@ +1887,5 @@ > + // All MathML tokens except <mtext> use 'math' script. > + textFlags |= gfxTextRunFactory::TEXT_USE_MATH_SCRIPT; > + } > + if (NS_MATHML_MATHVARIANT_NONE != f->StyleFont()->mMathVariant) { > + applyMathVariant = true; It looks like mathvariant="normal" will always call the MathMLTextRunFactory. Is it necessary? I believe we only need to remove the bold/italic font-style without char remapping. Calling AdjustFontStyle below should do that if you set the MathMLTextRunFactory::MATH_FONT_STYLING_NORMAL flag. I expect that in Bruce's example, things like <mi mathvariant="normal">x</mi> won't need any effort. @@ +1932,5 @@ > + uint8_t oldScriptLevel = 0; > + while (child->HasAnyStateBits(NS_FRAME_MATHML_SCRIPT_DESCENDANT) && > + parent) { > + // Reconstruct the script level ignoring any user overrides. It is > + // calculated this way instead of using scriptlevel to ensure the trailing space

Usage of the mathvariant attribute in Bruce's document: fred@debian:~/Bureau$ cat 10.22.txt | wc --lines 362 fred@debian:~/Bureau$ cat 10.22.txt | grep normal | wc --lines 340 fred@debian:~/Bureau$ cat 10.22.txt | grep bold | wc --lines 19 fred@debian:~/Bureau$ cat 10.22.txt | grep sans-serif | wc --lines 3 So shortcutting the mathvariant="normal" case seems important (However, I suspect the implicit single-char mi is even more present).

There are also 94 empty <mi>'s. Should we try to shortcut empty token elements too? (see also bug 1025164)

Try this build: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.bug@gmail.com-3842a820de57/ (It includes a since-withdrawn patch involving single-char <mi> elements and &nbsp;, but it shouldn't make much of a difference) For the most part minor improvements and rearranging. The check whether a single character <mi> is transformable is now more efficient. Per comment 19, it excludes empty or only whitespace tokens from the mathvariant processing. The number of iterations that the loop undergoes will be minimal as earlier code should have compressed whitespace. To keep it lightweight, the non-single char mi case assumes that any non-whitespace character is transformable, preventing the need to iterate over the entire string. The inclusion of &nbsp; is deliberate. It isn't transformable and the original string is left unaltered.

whitespace

Comment on attachment 8466206 [details] [diff] [review] Patch Review of attachment 8466206 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/generic/nsTextFrame.cpp @@ +1979,5 @@ > + } > + NS_ASSERTION(mathFontStyle->mMathVariant == NS_MATHML_MATHVARIANT_NONE || > + (mathFontStyle->mFont.style == NS_FONT_STYLE_NORMAL && > + mathFontStyle->mFont.weight == NS_FONT_WEIGHT_NORMAL), > + "This was supposed to have been set during CSS processing"); If someone does <mtext mathvariant="script" style="font-weight: bold">x</mtext> won't that raise the assertion? I don't really remember what was the "CSS processing", perhaps you should indicate to which part of the code it refers.

My test builds at http://www.wg9s.com/mozilla/firefox/ now have this patch applied for testing.

(In reply to James Kitchener (:jkitch) from comment #20) > Created attachment 8466204 [details] [diff] [review] > Patch > > Try this build: > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch. > bug@gmail.com-3842a820de57/ > (It includes a since-withdrawn patch involving single-char <mi> elements and > &nbsp;, but it shouldn't make much of a difference) Unfortunately, that didn't help (possibly even slower?). But there are new INFO messages appearing about basic_code_modules.cc that may be relevant? Here's the log: firefox/firefox -P noprofile -safe-mode -no-remote -new-instance (process:25733): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed (firefox:25733): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised (firefox:25733): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised (firefox:25733): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised (firefox:25733): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised 2014-08-02 09:08:25: stackwalker.cc:125: INFO: Couldn't load symbols for: /lib64/libc.so.6| 2014-08-02 09:08:25: stackwalker.cc:125: INFO: Couldn't load symbols for: /lib64/libfontconfig.so.1| 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x74bfa1249e077500 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea979d8 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x67 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed460 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed440 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398209240 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead5922 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398208f30 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398209261 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398208f38 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x74bfa1249e077500 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead3d00 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398209248 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead8360 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed540 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x408f480000000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x408f980000000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead8368 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x179db6b120 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x408f480000000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398209240 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e90cd40 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x100000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead35c0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed590 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd3982090c8 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e90cd40 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed704 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x31 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea13e00 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd3982090e0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed704 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1bf 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x788 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xf1 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e9168d0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eadd5a0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e90cd38 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e902000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed704 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed740 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e902000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed748 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x200000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e916148 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1bf 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed630 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b048 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed688 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eadff60 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd300000003 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eac7278 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd381fdc300 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xd6 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x74bfa1249e077500 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed718 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea15d00 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed940 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xd6 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd381fdc300 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: stackwalker.cc:125: INFO: Couldn't load symbols for: /archive/local/src/firefox/libxul.so| 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed704 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd381fdc300 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd389ed5d38 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed870 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed957 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed958 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd381fdc270 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xa6eadd550 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea01550 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b120 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x100000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eadd5a0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x4029000000000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eadd590 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xe0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b040 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed7a0 2014-08-02 09:08:25: stackwalker.cc:125: INFO: Couldn't load symbols for: | 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eadd5a0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1000000018 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xb3 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff00000002 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eae2000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37d800000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b048 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b200 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x200 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x100 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea13e00 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea13e00 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37d800000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed860 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1010 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed840 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed850 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b218 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b048 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x2a 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x6 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x6 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed870 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed868 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x8000000a00000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eac7278 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd300000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eac7278 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd300000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x6 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eac7f40 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed930 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b048 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed920 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x38 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eaacb80 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea15d00 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5edb68 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5edb80 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed970 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed970 2014-08-02 09:08:25: stackwalker.cc:125: INFO: Couldn't load symbols for: /archive/local/src/firefox/libmozalloc.so| 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea15d00 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eaacb80 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5edb40 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x4029000000000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3ff0000000000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x4029000000000000 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed9c8 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x800000140000000d 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd373c51828 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x50000000c 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf94668 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x50000000b 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf94648 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x500000007 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd373c51858 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x50000000c 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf94688 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x500000004 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd373c51918 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x500000011 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd373cf4438 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x50000000c 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf946a8 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x50000000b 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf946c8 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x500000005 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37a747c18 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x500000013 2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf946e8 1406984968187 GMPInstallManager.simpleCheckAndInstall INFO Last check was: 1082 seconds ago, minimum seconds: 86400 1406984968188 GMPInstallManager.simpleCheckAndInstall INFO Will not check for updates.

(In reply to Bill Gianopoulos [:WG9s] from comment #23) > My test builds at http://www.wg9s.com/mozilla/firefox/ now have this patch > applied for testing. For the record, that build gives the same behaviour as James' build; ie. slow & lots of INFO messages.

(In reply to Bruce Miller from comment #25) > (In reply to Bill Gianopoulos [:WG9s] from comment #23) > > My test builds at http://www.wg9s.com/mozilla/firefox/ now have this patch > > applied for testing. > > For the record, that build gives the same behaviour as James' build; > ie. slow & lots of INFO messages. Well, it's the same patch so I wouls expect the same results, unless one of the other patches included in my builds make it even slower (like the stretch one for example).

Here are the <mi> elements in Bruce's document. 2667 over 3094 <mi>'s are single latin & greek letters that need to be remapped, so the current patch won't really help here. However, I guess if the italic Mathematical Alphanumeric Symbols are used in the document by LaTeXML, the patch will avoid to do the remapping and make this fast... I think we should probably follow a fast path when rebuilding the text run for this ubiquitous case, perhaps using some kind of cache.

Try this: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.bug@gmail.com-a26d64738ab1 This introduces caching for length 1 TextRuns. Run this build using a profile you don't care about (add -p to the shortcut/launch command). It leaks and triggers a fatal assert on shutdown in debug builds. I'm holding off fixing these problems until I know if the patch is worthwhile. (The patch is here: https://hg.mozilla.org/try/rev/362f92c08877 , but it needs tidying up.) I've tried running the test page under a profiler, but I'm not sure I can trust the results. The profiler seems to blame everything on nsMathMLChar::SetFontFamily and the methods that call it. Specifically the hot code is apparently the copying and testing for equality of FontFamilyLists within nsFont objects. The problem is that SetFontFamily seems only to be triggered by <mo> elements, which shouldn't call the MathMLTextRunFactory after the ssty feature setting code was separated out in the previous patch.

(In reply to James Kitchener from comment #28) > I've tried running the test page under a profiler, but I'm not sure I can > trust the results. The profiler seems to blame everything on > nsMathMLChar::SetFontFamily and the methods that call it. Specifically the > hot code is apparently the copying and testing for equality of > FontFamilyLists within nsFont objects. > > The problem is that SetFontFamily seems only to be triggered by <mo> > elements, which shouldn't call the MathMLTextRunFactory after the ssty > feature setting code was separated out in the previous patch. Thanks. I think this is a separate perf problem with <mo> operators that is intended to be handled in bug 1009582.

Possibly a little faster (40secs) but definitely not "normal". I'm wondering what it might be about my system that causes it to be so slow on whatever the modern Gecko is doing differently. Apparently, you guys are not seeing much or any slowdown? I see some other folks grousing about Firefox 28 being slow in general, but I doubt they're even looking at MathML; maybe it isn't even completely specific to MathML?

(In reply to Bruce Miller from comment #30) > Possibly a little faster (40secs) but definitely not "normal". > > I'm wondering what it might be about my system that causes it to be > so slow on whatever the modern Gecko is doing differently. > Apparently, you guys are not seeing much or any slowdown? No, the page definitely does not take more than a few seconds to load for me. > I see some other folks grousing about Firefox 28 being slow in general, > but I doubt they're even looking at MathML; maybe it isn't even completely > specific to MathML? Well, here the patch that disabled mathvariant fixed the problem, so that's necessarily something here. Perhaps a gfx issue... I know that Fedora has specific build config and obviously Windows uses different graphic libraries. Karl may know more about that. [An option would be to disable the math italic remapping conditionally, at build time or using a preference. The CSS italic is already used as a fallback when math italic glyphs are missing. However, that will definitely change the rendering of italic variable...] (In reply to James Kitchener from comment #28) > (The patch is here: https://hg.mozilla.org/try/rev/362f92c08877 , but it > needs tidying up.) I can't access it...

(In reply to Frédéric Wang (:fredw) from comment #31) > > (The patch is here: https://hg.mozilla.org/try/rev/362f92c08877 , but it > > needs tidying up.) > > I can't access it... Attached. No effort has been made to tidy it up, and I have some doubts regarding the potential for false positives and false negatives.

Comment on attachment 8469941 [details] [diff] [review] Rough caching attempt Review of attachment 8469941 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/generic/MathMLTextRunFactory.cpp @@ +632,5 @@ > nsRefPtr<gfxFontGroup> newFontGroup = aFontGroup->Copy(&fontStyle); > return newFontGroup.forget(); > } > > +#define TEXTRUN_CACHE_SIZE 16 fred@debian:~/Bureau$ cat 10.22 | uniq | grep -v mathvariant | wc --lines 36 So Bruce's document will exceed cache size. 40s is already a 33% improvement over 60s. I wonder if we get better result with a larger limit (something like 26 * 2 letters?). Also, at some point the mathvariant="normal" optimization might become important. I don't know if that was included in the latest build.

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.bug@gmail.com-f8d4802ff205 The cache is now a 52 entry hashtable. The earlier warning about using a profile you don't care about still applies.

Try the build from comment 34.

> Created attachment 8470387 [details] [diff] [review] > Rough caching attempt > > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch. > bug@gmail.com-f8d4802ff205 Nope, didn't really help; still about 45secs.(In reply to James Kitchener from comment #34)

(In reply to Bruce Miller from comment #30) > I'm wondering what it might be about my system that causes it to be > so slow on whatever the modern Gecko is doing differently. > Apparently, you guys are not seeing much or any slowdown? Yes. It is up to about 10 seconds here, but it is a little inconsistent due to times for network response. To remove the network effect use Ctrl+- and Ctrl+= to resize larger and smaller. This should test the rendering without the network effects. Please also check http://www.wikipedia.org/ which should take no more than a couple of seconds. It may be faster when resized to a size that has been drawn before, due to caching. We've had some absurdly slow responses from fontconfig before due to some files having timestamps in the future and so caches are always out of date. Please run "fc-cache -v" and report whether there are any lines that do not match any of these: ": skipping, existing cache is valid" ": not cleaning unwritable cache directory" ": cleaning cache directory" ": succeeded"

One thing I notice is that MathMLTextRunFactory::RebuildTextRun() is creating a new gfxFontGroup for each text run. That misses out on caching of font selection, usually provided by nsDeviceContext::GetMetricsFor(). http://hg.mozilla.org/mozilla-central/annotate/6a7be7376caa/layout/generic/MathMLTextRunFactory.cpp#l703 http://hg.mozilla.org/mozilla-central/annotate/6a7be7376caa/gfx/src/nsDeviceContext.cpp#l261

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.bug@gmail.com-430656ceccbc This skips the creation of a new gfxFontGroup. It doesn't include the other patches. Depending on your fonts it may not render italics/bold, but I'm more concerned about rendering speed.

(In reply to Karl Tomlinson (:karlt) from comment #37) > We've had some absurdly slow responses from fontconfig before due to some > files having timestamps in the future and so caches are always out of date. > Please run "fc-cache -v" and report whether there are any lines that do not > match any of these: > > ": skipping, existing cache is valid" > ": not cleaning unwritable cache directory" > ": cleaning cache directory" > ": succeeded" I'm getting: > fc-cache -v | grep -v 'skipping, existing cache is valid' | grep -v 'not cleaning unwritable' /usr/local/share/fonts: skipping, no such directory /home/bruce/.local/share/fonts: skipping, no such directory /home/bruce/.fonts: skipping, no such directory Re-scanning /usr/share/fonts: caching, new cache contents: 0 fonts, 238 dirs Re-scanning /usr/share/fonts/KOI8-R: caching, new cache contents: 0 fonts, 3 dirs Re-scanning /usr/share/fonts/default: caching, new cache contents: 0 fonts, 2 dirs Re-scanning /usr/share/fonts/iso8859-2: caching, new cache contents: 0 fonts, 3 dirs Re-scanning /usr/share/fonts/japanese: caching, new cache contents: 0 fonts, 1 dirs Re-scanning /usr/share/fonts/sazanami: caching, new cache contents: 0 fonts, 2 dirs /home/bruce/.cache/fontconfig: cleaning cache directory /home/bruce/.fontconfig: cleaning cache directory fc-cache: succeeded Don't know much about what that means, or why it's re-scanning those directories.

(In reply to James Kitchener from comment #39) > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch. > bug@gmail.com-430656ceccbc > > This skips the creation of a new gfxFontGroup. It doesn't include the other > patches. Bingo! That seems to be the problem: your patch brought it down to around 7-8 seconds!! It could be that the other optimizations you were looking at will show up now that the main slowdown is solved, but this appears to be the main issue. Thanks!! > Depending on your fonts it may not render italics/bold, but I'm more > concerned about rendering speed. I seem to be seeing them all... (sorry for the delay in testing)

This fetches the gfxFontGroup objects from whatever is responsible for caching them. This supersedes the other two patches. Debugging/profiling indicates the MathMLTextRunFactory related code isn't run frequently enough for the streamlining patch to be useful and the attempt at caching TextRuns is very nasty. If you could please confirm that the approach works, I'll flag this for review. https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.bug@gmail.com-c6461094d22e I'm inclined to blame much of the remaining slowness on bug 1009582, as my profiler isn't highlighting any other issues.

(In reply to James Kitchener from comment #42) > Created attachment 8475128 [details] [diff] [review] > This supersedes the other two patches. Debugging/profiling indicates the > MathMLTextRunFactory related code isn't run frequently enough for the > streamlining patch to be useful and the attempt at caching TextRuns is very > nasty. I think skipping the MathMLTextRunFactory stuff when mathvariant="normal" is easy to do, though. > I'm inclined to blame much of the remaining slowness on bug 1009582, as my > profiler isn't highlighting any other issues. @Bruce: can you also try your test page with all the <mo>'s replaced by <mtext>'s? This will allow to ignore potential slowness due to bug 1009582.

(In reply to Bruce Miller from comment #40) > Re-scanning /usr/share/fonts: caching, new cache contents: 0 fonts, 238 dirs > Re-scanning /usr/share/fonts/KOI8-R: caching, new cache contents: 0 fonts, 3 > dirs > Re-scanning /usr/share/fonts/default: caching, new cache contents: 0 fonts, > 2 dirs > Re-scanning /usr/share/fonts/iso8859-2: caching, new cache contents: 0 > fonts, 3 dirs > Re-scanning /usr/share/fonts/japanese: caching, new cache contents: 0 fonts, > 1 dirs > Re-scanning /usr/share/fonts/sazanami: caching, new cache contents: 0 fonts, > 2 dirs This would be slowing down the browser, even for pages without MathML. Check each directory with "ls -lart" for files or dirs with funny timestamps.

(In reply to James Kitchener from comment #42) > Created attachment 8475128 [details] [diff] [review] > Patch allowing font caching > > This fetches the gfxFontGroup objects from whatever is responsible for > caching them. > > This supersedes the other two patches. Debugging/profiling indicates the > MathMLTextRunFactory related code isn't run frequently enough for the > streamlining patch to be useful and the attempt at caching TextRuns is very > nasty. > > If you could please confirm that the approach works, I'll flag this for > review. > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch. > bug@gmail.com-c6461094d22e > > I'm inclined to blame much of the remaining slowness on bug 1009582, as my > profiler isn't highlighting any other issues. When you do get a review ready patch please also post a diff -w. This is one of those cases where it would be helpful.

(In reply to Frédéric Wang (:fredw) from comment #43) > @Bruce: can you also try your test page with all the <mo>'s replaced by > <mtext>'s? This will allow to ignore potential slowness due to bug 1009582. Making a local copy of the page (& dependencies) and re-running as-is took around 6 secs (removing network effects?); Replacing all the <mo>'s with <mtext>'s reduced that to around 2-3 secs, so there's indeed still a big (percentage-wise) potential improvement. Doesn't look as good, though! :>

(In reply to Karl Tomlinson (:karlt) from comment #44) > (In reply to Bruce Miller from comment #40) > > Re-scanning /usr/share/fonts: caching, new cache contents: 0 fonts, 238 dirs > > Re-scanning /usr/share/fonts/KOI8-R: caching, new cache contents: 0 fonts, 3 > > dirs > > Re-scanning /usr/share/fonts/default: caching, new cache contents: 0 fonts, > > 2 dirs > > Re-scanning /usr/share/fonts/iso8859-2: caching, new cache contents: 0 > > fonts, 3 dirs > > Re-scanning /usr/share/fonts/japanese: caching, new cache contents: 0 fonts, > > 1 dirs > > Re-scanning /usr/share/fonts/sazanami: caching, new cache contents: 0 fonts, > > 2 dirs > > This would be slowing down the browser, even for pages without MathML. > > Check each directory with "ls -lart" for files or dirs with funny timestamps. Nothing that jumps out at me; no future dates, for example. Note that I ran that as non-root; looking at the man page suggests that I ought to run it, probably as root, with the -f and maybe -r options, to completely refresh the caches? Even so, I think I'll wait till we sort out the current issue, so as not to throw off the comparisons.

@Bruce: so did you reply positively to James' comment 42? i.e. does his last patch still fixes the issue?

Yes indeed, my comment #45 was replying to both your #43 and James' #42 using the build linked to from there.

(In reply to James Kitchener from comment #42) > Created attachment 8475128 [details] [diff] [review] > Patch allowing font caching Just a heads-up that this patch has bit-rotted slightly. Fix is to replace both instances of -moz-font-feature-settings with font-feature-settings in the patch file.

BTW. I am now including this patch in my nightly builds with other MathML enhancements available here http://www.wg9s.com/mozilla/firefox/

Patch with diff -w for convenience.

(See comment 52 for a whitespace ignoring diff of this patch). Previously the MathMLTextRunFactory created a new gfxFontGroup every time it was called, preventing font caching from working properly. The attached patch now performs font manipulation on nsFont objects, allowing gfxFontGroup caching to work properly. The remaining changes (rephrasing a comment and a slight reduction in the number of times the MathMLTextRunFactory is created) are minor.

whitespace fix.

Comment on attachment 8477341 [details] [diff] [review] Patch allowing font caching Review of attachment 8477341 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!!!

Try run: https://tbpl.mozilla.org/?tree=Try&rev=e7e1cd68bb1c

We forgot about comment 12 here. I think we should try to make a talos test from a page with many <mi>'s and mathvariant's (and without stretchy/large op since that's a separate problem). https://wiki.mozilla.org/Buildbot/Talos#Adding_a_new_test

Frédéric, I will try it and sorry for the delay.

(In reply to Bruce Miller from comment #47) > Nothing that jumps out at me; no future dates, for example. > > Note that I ran that as non-root; looking at the man page suggests that I > ought to > run it, probably as root, with the -f and maybe -r options, to completely > refresh the caches? > Even so, I think I'll wait till we sort out the current issue, so as not to > throw off the comparisons. Bill recalled that comment during the MathML meeting... Did you try to refresh your font cache and to run the test again with a recent nightly build? Just to see whether that improves your last result...

How complicated does the test need to be? Would several thousand <mi> elements, with randomised alphanumeric content and random mathvariant attributes be sufficient?

(In reply to James Kitchener from comment #62) > How complicated does the test need to be? > > Would several thousand <mi> elements, with randomised alphanumeric content > and random mathvariant attributes be sufficient? Yes, I think so since the bottleneck was the font caching in the MathMLTextRunFactory, and no other MathML constructions were actually involved.

(In reply to Frédéric Wang (:fredw) from comment #61) > (In reply to Bruce Miller from comment #47) > > Nothing that jumps out at me; no future dates, for example. > > > > Note that I ran that as non-root; looking at the man page suggests that I > > ought to > > run it, probably as root, with the -f and maybe -r options, to completely > > refresh the caches? > > Even so, I think I'll wait till we sort out the current issue, so as not to > > throw off the comparisons. > > Bill recalled that comment during the MathML meeting... Did you try to > refresh your font cache and to run the test again with a recent nightly > build? Just to see whether that improves your last result... I did try to rebuild the cache, but I don't think it worked: I still get messages about Re-scanning. Poking around at it, it looks like the directories that cause it to rescan * contain other directories * contain gzipped files, like b10.pcf.gz (rather than plain .ttf, .pcf, etc) In those cases, it says soemthing like: Re-scanning /usr/share/fonts/KOI8-R: caching, new cache contents: 0 fonts, 3 dirs ie. it ends up with "0 fonts". Curiously, fc-list *does* list the gzipped fonts in those directories. Any ideas on how to eliminate the re-scan? (It should be clear by now, I'm clueless on font caches!)

(In reply to Bruce Miller from comment #64) > Any ideas on how to eliminate the re-scan? (It should be clear by now, I'm > clueless on font caches!) I don't know what is happening there. Perhaps running fc-cache with FC_DEBUG=432 in the environment might provide some clues, or use different values for less verbosity. http://www.freedesktop.org/software/fontconfig/fontconfig-user.html#DEBUG If this is on an old OS distribution, then there may be a fontconfig bug that has been fixed in more recent versions.