nsThebesFontMetrics::GetMaxStringLength is slow




13 years ago
12 years ago


(Reporter: bzbarsky, Unassigned)



Dependency tree / graph
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)


I just profiled one of the testcases from bug 64858 in a thebes and a GTK2/XFT build and compared the two profiles.  One of the things that jumped out at me is that in the thebes build about 1.5% of total page load time was spent in (not under, in) nsThebesFontMetrics::GetMaxStringLength.  For GTK2 the equivalent number was much much lower (about 10x less, in fact).  This is all with Mark's patch for bug 334064.

The problem is that this function is called a lot, due to the fix for bug 237085 (and I'll file a separate bug on its being called too much).  The GTK2 code just has the value to be returned as a member and returns it; the thebes code has to compute this value...  I would assume the result is a perf hit on all our platforms, since the computation is in XP code.

Would it be possible to cache the number we actually want to return here?
Filed bug 351126 on GetMaxStringLength getting called when not needed.
Flags: blocking1.9?
For Thebes most of the string measurement and rendering code is going to be replaced on trunk with the new gfxTextRun API. (I am working on this currently.) Each platform's implementation of gfxTextRun will be required to handle arbitrary length strings. So GetMaxStringLength will not exist for Thebes in its current form.

Perhaps we should make this depend on the textframe rewrite. I don't think we have a bug for that yet --- do we, vlad, pav?
This shows up on Windows as well in the profilers.

I don't think there is a new textframe bug.
OS: Linux → All
OK, I filed "rewrite nsTextFrame" as bug 351242.
Depends on: 351242
No longer depends on: 351242
code will be going away
Flags: blocking1.9? → blocking1.9-
Now that gfxTextRun has landed should this bug be closed?
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.