(kindly let me know if I am missing something here) The mLoadedFonts array is part of the nsFontMetricsGTK class which are created on a per-element basis. Consider a document with a series of elements with the same metrics: <font xxx> text <tag>text</tag> text <tag>text</tag> text <tag>text</tag> ... </font> The list of fonts for each element will be identical but as we do not share the nsFontMetricsGTK (or mLoadedFonts) instance between elements the font code must run the lookup code for each one. Since the font lookup code can do an extensive amount of searching to find certain glyphs it seems like a reasonable thing to not duplicate that effort. I believe that this is the case in Linux and as Erik wrote the code for Mac and Windowes I suspect that code is similar. Perhaps one of the layers above the nsFontMetricsXXX layer could implement the sharing. If that is difficult then the mLoadedFonts list could be shared.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Summary: share nsFontMetrics or mLoadedFonts to reduce the number of font lookups → share nsFontMetrics/mLoadedFonts to reduce font lookups
bstell, isn't this already taken care of by the nsFontCache?
When I turn on font debug I see the font search being repeated. Can you suggest a developer to ask about this?
That's because the nsFontCache is attached to nsDeviceContext, and there could be several device context instances around, meaning multiple font caches (c.f. bug 91956). Each device context can have its own text zoom and such, resulting in different actual font metrics, so things can get a bit trickier.
> Each device context can have its own text zoom and such, resulting > in different actual font metrics, so things can get a bit trickier. Just sharing a font metrics where the metrics are identical would be a nice win on pages few font changes but lots of links.
It will shed light to understand why multiple DCs with the same characteristics are even created in the first place (indeed, from your comments, it is strange that multiple links on the same page entail multiple DCs). The issue could become moot if gratuitous DCs were avoided.
I built a test case and I see that it is not doing a font search every element. Here is the test case: <font face="arial"> string1 <a href="...">string2</a> string3 <a href="...">string4</a> string5 <a href="...">string6</a> </font> and it only did 2 searches. I assume that one search is for the regular text and the other is for the link text. This seems okay. My misunderstanding.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
Marking as verified, please reopen in case someone disagrees.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.