share nsFontMetrics/mLoadedFonts to reduce font lookups

VERIFIED INVALID

Status

()

Core
Internationalization
VERIFIED INVALID
17 years ago
17 years ago

People

(Reporter: kill this account, Assigned: kill this account)

Tracking

Trunk
Future
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

17 years ago
(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.
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future
(Assignee)

Updated

17 years ago
Summary: share nsFontMetrics or mLoadedFonts to reduce the number of font lookups → share nsFontMetrics/mLoadedFonts to reduce font lookups

Comment 1

17 years ago
bstell, isn't this already taken care of by the nsFontCache?
(Assignee)

Comment 2

17 years ago
When I turn on font debug I see the font search being repeated.

Can you suggest a developer to ask about this?


Comment 3

17 years ago
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.
(Assignee)

Comment 4

17 years ago
> 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.

Comment 5

17 years ago
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.
(Assignee)

Comment 6

17 years ago
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: 17 years ago
Resolution: --- → INVALID

Comment 7

17 years ago
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.