It looks like we added TwemojiMozilla.ttf in bug 1231701 for Windows XP and 7, where presumably built-in Emoji fonts weren't amazing.

Is Windows 10 any better? Can we special-case for Windows 7, and not load this at all for Windows 10?

Here's a cold startup profile where loading that .ttf takes about 1 second: https://share.firefox.dev/3bxi40J

Hey jfkthame, do you know what the current story is on the TwemojiMozilla.ttf font?

We could consider skipping it on Win8.1 and later, I guess, as Segoe UI Emoji should be present there. Last I checked, ISTR there were some emoji glyphs that aren't supported in Segoe UI Emoji but were provided by Twemoji, but that may not be worth worrying about; just relying on what the platform provides should be adequate (and Microsoft will no doubt continue to extend the Segoe UI Emoji coverage over time).

I think this should be relatively straight-forward to do.

The simple thing to do here is to just skip the bundled-font loading operation altogether on recent Windows versions, as Twemoji is the only font we ship in this way. If some day we have other fonts we want to bundle, we could make the enumerator smarter so it selectively skips depending on the version, or separate fonts into subdirectories for different Windows versions, or something. But let's not worry about that until/unless the need arises.

(Oh, I wonder if the Tor browser uses this mechanism to provide specific fonts? If so, they might be affected if we simply kill it on Win8.1/Win10. Tom, do you know if this would be an issue?)

Let me pass to the Tor Browser devs, this bit of TB I've not encountered.

This allows us to default to skipping the bundled Twemoji Mozilla font when running on Win8.1 or later,
where we can assume Segoe UI Emoji is available.

The new pref here replaces the existing pair of boolean prefs that were only supported on Android,
and is now respected on all platforms. Available settings are:

0     disable use of app-bundled fonts
> 0   enable use of app-bundled fonts
< 0   default (auto): decide at startup, based on the system environment

(The pref is relevant only at startup; changing its value during a session will not make the bundled fonts
appear/disappear dynamically.)

(In reply to Jonathan Kew (:jfkthame) from comment #4)

(Oh, I wonder if the Tor browser uses this mechanism to provide specific fonts? If so, they might be affected if we simply kill it on Win8.1/Win10. Tom, do you know if this would be an issue?)

Currently, on all Windows platforms we compile with |MOZ_BUNDLED_FONTS| and bundle a few additional fonts, along with setting |font.system.whitelist| as a list containing some system fonts and the additional bundled fonts. We can set |
gfx.bundled-fonts.activate| as 1, that's fine for us.

Thanks

Sounds good - thanks for confirming. I figured if we provide a pref so that you can force the behavior one way or the other, that should cover things.

https://hg.mozilla.org/mozilla-central/rev/23756a8322ec

Any chance there's a way to have the fallback to Twemoji for the Unicode range representing flags? Otherwise, you've introduced a visual regression because Windows 10's emoji font is nerfed to omit all country flags.

https://twitter.com/ericlaw/status/1366421321131950088

(In reply to Eric Lawrence (@ericlaw) from comment #11)

Any chance there's a way to have the fallback to Twemoji for the Unicode range representing flags? Otherwise, you've introduced a visual regression because Windows 10's emoji font is nerfed to omit all country flags.

https://twitter.com/ericlaw/status/1366421321131950088

--> :jfkthame ?

(In reply to :Gijs (he/him) from comment #12)

(In reply to Eric Lawrence (@ericlaw) from comment #11)

Any chance there's a way to have the fallback to Twemoji for the Unicode range representing flags? Otherwise, you've introduced a visual regression because Windows 10's emoji font is nerfed to omit all country flags.

https://twitter.com/ericlaw/status/1366421321131950088

--> :jfkthame ?

Well... that's indeed the expected result of turning off the loading of Twemoji on Win10: we rely on Microsoft's font to render emoji, and MS hasn't seen fit to support the country-flag ligatures. Presumably that's the same result users will see in other browsers, too, so it'll be consistent for all applications on the platform.

If users want to keep the Twemoji font, so that emoji that aren't supported by the OS font can still be rendered, setting gfx.bundled-fonts.activate to 1 will do this. The downside (apart from making Firefox's rendering less consistent with other browsers/applications on the same system, though in some cases it may be preferable) is a potential increase in startup time (as per comment 0).

:mconley, how do you feel about this, given you originally filed this? Should we favor startup time or emoji flags (by default)?

:mconley, how do you feel about this, given you originally filed this? Should we favor startup time or emoji flags (by default)?

Is it at all possible to load this font after gfxPlatform::Init off of the main thread? My primary concern is startup time, but if the content process can eventually have access to the Twemoji fonts, perhaps that's the best of both worlds.

Possible in theory, yes; but that comes with significant downsides too: we'd then have to rebuild the platform font list (we can't gradually mutate it -- when the set of available fonts changes, we throw it away and start again), and that in turn means we have to completely reflow everything in all processes (because all the font references hanging off the textruns in the frame tree etc will become invalid).

On the whole I don't think we want to be doing that; at whatever point we decide to add Twemoji to the available fonts, we're liable to end up janking all processes because changing the font list disrupts everything. (Normally, we don't expect the available font collection to be changing while we're running, or at least not while the user is actively using the browser -- if they've clicked over to Windows Explorer to install a new font, the browser is in the background and it probably doesn't matter so much if it momentarily janks when the font gets activated.)

In that case, this is probably a Product call. Maybe mbalfanz?

1s slower startup time for loading the font seems very significant. What percentage of the overall startup time does this occupy? Also, how would it change if we only consider the subset of the font that we actually need for showing the flags?

I suspect 1s may be a fairly extreme outlier; I'm generally seeing only a few milliseconds here on my ThinkPad, for example. Across a number of attempts at profiling startup with gfx.bundled-fonts.activate set to 1, the most I saw under gfxPlatformFontList initialization was 30ms, and most of that was in other DirectWrite calls (much of it under GetDefaultFontForPlatform) that we'd be making regardless of the bundled emoji font.

Mike, can you comment on how consistently you're seeing a really slow startup here, if you set gfx.bundled-fonts.activate back to 1 so that the font is activated? What kind of machine is this on? I'm aware that my ThinkPad was once a relatively high-end laptop (i7, 2.9GHz, 16GB), but on the other hand it's 5+ years old so not necessarily representative of current machines.

Can we delay loading Twemoji until a web page actually requires the glyphs or metrics? It should be rare as long as Twemoji is behind Segoe UI emoji. We have to read the name table to determine the font name, but we already know the name in this case.

I'm hesitant to try that for a couple of reasons. One is that it'd introduce a font-list rebuild at an unexpected time, with the associated jank (across all processes) as all content has to be completely reflowed (because rebuilding the font list invalidates all existing font references).

There's also the question of exactly what conditions we'd use to trigger such behavior: would we load the font if a page requests it using font-family? That means adding a special-case test every time we're resolving a font-family list. Or would we load it only if we encounter regional-indicator characters and are attempting to find a fallback font to display them? If so, there could then be unexpected side-effects on other pages: if a page was styled with font-family: Twemoji Mozilla, Segoe UI Emoji, ... for general emoji content, the rendering would suddenly change when some other page happens to try and render a flag. (Also, would we attempt to load the Twemoji font if we encounter one of the other (non-flag) emoji characters that's not currently supported in Segoe UI Emoji? How would we maintain such a list?)

I think there are too many costs and complications for this to be a good option. Either we decide that supporting the flags (and other new emoji that may be missing from Segoe) by default is important enough that we'll risk occasional slow startups (I'd still like to know how bad/how common this is), and so we should activate the font always; or we decide that we're accepting the default Windows rendering, where regional-indicator characters display as letter pairs (that seems to be Microsoft's choice, at least for now), and tell users who want Twemoji to be used that they need to explicitly enable it in prefs.

(In reply to Jonathan Kew (:jfkthame) from comment #18)

I suspect 1s may be a fairly extreme outlier; I'm generally seeing only a few milliseconds here on my ThinkPad, for example.

I would guess your ThinkPad has an ssd, so very different I/O timings.

Mike, can you comment on how consistently you're seeing a really slow startup here

I/O is typically expensive during cold startup (ie. first startup of Firefox after a reboot of the computer) for machines with a mechanical drive (SSD users are still a minority of our users). Antivirus software (eg. McAfee) also makes I/O significantly slower.

Florian answered in comment 21. I believe the profile that caused me to file this bug was actually from one of Florian's machines - either one of the reference devices, or one of his other test devices.