If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[@font-face] implement more selective download algorithm

RESOLVED INVALID

Status

()

Core
Graphics
P2
major
RESOLVED INVALID
8 years ago
2 years ago

People

(Reporter: jtd, Assigned: jtd)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

8 years ago
Given multiple downloadable fonts in a font list, we currently download all fonts before the first platform font:

  body {
    font-family: downloadable-font-A, downloadable-font-B, platform-font-A;
  }

The font matching logic is currently:

 for each font
   if (downloadable and not loaded)
     start download
   else
     if glyph exists for character, found match and stop searching

So in the example above, both downloadable fonts will be downloaded because until the fonts are loaded the first font containing a glyph for the character is the platform font.

An optimization of this would be:

 for each font
   if (downloadable and not loaded)
     if (no font in this list is already downloading) start download
   else
     if glyph exists for character, found match and stop searching

This appears to be Safari behavior, although Safari has problems with proper fallback when downloadable fonts are involved.

Typically font lists won't include multiple downloadable fonts, a single downloadable font followed by multiple platform fonts is more likely.  The downside of the optimization is that for complex fallback situations, several load-reflow cycles will occur before the page renders as intended.
(Assignee)

Updated

7 years ago
Duplicate of this bug: 579916
(Assignee)

Updated

7 years ago
Assignee: nobody → jdaggett
(Assignee)

Updated

7 years ago
Severity: normal → major
Priority: -- → P2

Comment 2

7 years ago
The use-case here is to allow a small font deliverable containing the common glyphs catering for, say, 95% of cases. 

The second font in the list would be in the same style but contain extended chars.

The downside is these fonts download in series.
John, what's the status on this one?
(In reply to Jake Archibald from comment #2)
> The use-case here is to allow a small font deliverable containing the common
> glyphs catering for, say, 95% of cases. 
> 
> The second font in the list would be in the same style but contain extended
> chars.
> 
> The downside is these fonts download in series.

This sounds like a use case where the unicode-range descriptor (which we don't yet support - bug 475891) should be used.
(Assignee)

Comment 5

6 years ago
(In reply to Bas Schouten (:bas) from comment #3)
> John, what's the status on this one?

This is an optimization that's still worth doing but I don't consider a huge issue.
I've posted a few additional examples that demonstrate the problem here:

  http://people.mozilla.org/~jkew/lazy-fontface-1.html
  http://people.mozilla.org/~jkew/lazy-fontface-2a.html
  http://people.mozilla.org/~jkew/lazy-fontface-2b.html

The pages each include a note of what the desired behavior would be; use the Web Console (reload the pages after opening it) to see the downloads that are performed. We currently download all the font resources linked from these testcases, even those that are never actually used.

I have some WIP patches (not quite review-ready yet, but I think they're close) that address this for platforms using gfxPlatformFontList to manage fonts (Mac/Win/Android). They don't fix it for the fontconfig-based Linux environment, where our font management and font-matching code is structured quite differently.

BTW, using the Developer Tools in Chrome confirms that it handles lazy-fontface-1.html as expected (it doesn't download the @font-face resource), but doesn't do so well on 2a/2b (it downloads all three fonts, although only one or two respectively should have been fetched).
(Assignee)

Comment 7

2 years ago
No longer valid, changes for unicode-range have improved the load handling of webfonts.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.