Open Bug 918171 Opened 11 years ago Updated 2 years ago

improve efficiency of userfont cache

Categories

(Core :: Graphics: Text, defect)

defect

Tracking

()

People

(Reporter: jtd, Unassigned)

References

Details

The way the userfont cache works has a couple problems that lead to less than ideal caching of userfonts.  The first problem is that the cache key includes a reference to a principal.  This can actually change if script decides to modify document.domain for example.  As far as I can tell, this isn't necessary since before any load occurs the combination of principal and font URI are checked.

The other problem is a timing/efficiency one.  If multiple tabs load concurrently containing pages from a site that uses the same downloadable fonts across all pages, then the existing userfont cache often will contain multiple copies of the same font.  The sequence of steps is:

1. Page1 attempts to use fontA.  It's not in the cache, so it starts the load
2. Page2 also attempts to use fontA.  As in (1), it starts the load, since userfonts are managed per-document.
3. Page1 load of fontA completes and fontA is stored in the userfont cache
4. Page2 load of fontA completes and a second copy of fontA is stored in the userfont cache

Here's the set of fonts stored in the userfont cache when loading the pages listed in bug 838105, comment 35:

userfontcache fontEntry: 0x1770618b0 fonturihash: 317a78be family: BebasNeue domainset: false principal: [http://arstechnica.com/information-technology/2013/08/vmwares-dual-persona-tech-hits-big-name-android-models-but-not-iphone/]
userfontcache fontEntry: 0x167c87420 fonturihash: 317a78be family: BebasNeue domainset: true principal: [http://arstechnica.com/gaming/2013/08/nintendo-lowering-price-of-32gb-deluxe-wii-u-to-299-on-september-20/]
userfontcache fontEntry: 0x16fdddaa0 fonturihash: 317a78be family: BebasNeue domainset: true principal: [http://arstechnica.com/gaming/2013/08/microsoft-refutes-conspiracies-about-xbox-one-drm-bait-and-switch/]
userfontcache fontEntry: 0x16e7b01f0 fonturihash: 317a78be family: BebasNeue domainset: true principal: [http://arstechnica.com/security/2013/08/twitter-and-new-york-times-clash-with-hackers-for-control-of-their-sites/]
userfontcache fontEntry: 0x16c93fa50 fonturihash: 317a78be family: BebasNeue domainset: true principal: [http://arstechnica.com/]
userfontcache fontEntry: 0x16e7b06d0 fonturihash: 681c65d7 family: NoticiaBold domainset: true principal: [http://arstechnica.com/security/2013/08/twitter-and-new-york-times-clash-with-hackers-for-control-of-their-sites/]
userfontcache fontEntry: 0x167c87900 fonturihash: 681c65d7 family: NoticiaBold domainset: true principal: [http://arstechnica.com/gaming/2013/08/nintendo-lowering-price-of-32gb-deluxe-wii-u-to-299-on-september-20/]
userfontcache fontEntry: 0x17572efc0 fonturihash: 681c65d7 family: NoticiaBold domainset: false principal: [http://arstechnica.com/information-technology/2013/08/vmwares-dual-persona-tech-hits-big-name-android-models-but-not-iphone/]
userfontcache fontEntry: 0x16fddd1b0 fonturihash: 681c65d7 family: NoticiaBold domainset: true principal: [http://arstechnica.com/gaming/2013/08/microsoft-refutes-conspiracies-about-xbox-one-drm-bait-and-switch/]
userfontcache fontEntry: 0x16daa7570 fonturihash: 681c65d7 family: NoticiaBold domainset: true principal: [http://arstechnica.com/]
userfontcache fontEntry: 0x16daa7710 fonturihash: 3a31f5ca family: NoticiaBoldItalic domainset: true principal: [http://arstechnica.com/]
userfontcache fontEntry: 0x16e7b0940 fonturihash: 3a31f5ca family: NoticiaBoldItalic domainset: true principal: [http://arstechnica.com/security/2013/08/twitter-and-new-york-times-clash-with-hackers-for-control-of-their-sites/]

There really should only be three entries here!

The solution is to (1) remove the principal from the key and (2) do a lookup in the cache after the load completes to avoid duplicate entries.
Assignee: nobody → jdaggett
Depends on: 838105
I think a better solution to (2) here would be to manage the user font loads more centrally. As soon as page1 starts loading fontA, record this in the cache (the existing user font cache or a separate loads-in-progress cache?), so that when page2 also wants fontA, it does NOT kick off an additional network request, but just refers to the existing one. Then when the load completes, it would notify all the relevant documents or font sets, not only the one that originally initiated the load.
Assignee: jd.bugzilla → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.