1766908 - Slow loading of OS fonts on startup and when restoring tabs

Status: RESOLVED INCOMPLETE

(Core :: Graphics: Text, defect)

Description

[clessili]

Probably related to bug 1688951
I see a pretty long hang/pause on startup when restoring a session, and occasionally when restoring a tab. Firefox basically draws its window nearly instantly, then sits still for about 2.1 seconds before loading the page.

I tried deleting the font cache in system32, restarting the Font Cache Service, deleting fonts from my system, removing font lists from about:config. It did seem to alleviate the issue, because the following profiles are a lot less impressive than when I first tried to look for a solution.

Here's a recent startup profile: https://share.firefox.dev/3rXtW3x
And when switching to a tab: https://share.firefox.dev/3koBJTK

This is on a Win10 PC equipped with a Core i9-9900K and a fast NVMe, so these hangs look and feel relatively big.

One strange thing to note: a near instant loading is possible ONCE by signing out of my Firefox Account, restarting, signing in, then restarting. During this last restart, the issue is not visible. All restarts after that are slow again.

I tried looking at the code and savagely butchering some of the lines in gfx/thebes/gfxPlatformFontList.cpp.
Changing line 247:

/* static */
bool gfxPlatformFontList::Initialize(gfxPlatformFontList* aList) {
  sPlatformFontList = aList;
  if (XRE_IsParentProcess() &&
      StaticPrefs::gfx_font_list_omt_enabled_AtStartup() &&
      StaticPrefs::gfx_e10s_font_list_shared_AtStartup() &&
      !gfxPlatform::InSafeMode()) {
    sInitFontListThread = PR_CreateThread(
        PR_USER_THREAD, InitFontListCallback, aList, PR_PRIORITY_NORMAL,
        PR_GLOBAL_THREAD, PR_JOINABLE_THREAD, 0);
    return true;
  }
  if (aList->InitFontList()) {
    return true;
  }
  Shutdown();
  return false;
}

to:

/* static */
bool gfxPlatformFontList::Initialize(gfxPlatformFontList* aList) {
  sPlatformFontList = aList;

    sInitFontListThread = PR_CreateThread(
        PR_USER_THREAD, InitFontListCallback, aList, PR_PRIORITY_NORMAL,
        PR_GLOBAL_THREAD, PR_JOINABLE_THREAD, 0);
    return true;
}

makes restoring sessions and tabs instantaneous, but I should stress I have no idea what I'm doing, or if the expected behaviour is to enter this first if.

Even changing it to this did not trigger a crash:

/* static */
bool gfxPlatformFontList::Initialize(gfxPlatformFontList* aList) {
  sPlatformFontList = aList;
  if (XRE_IsParentProcess() &&
      StaticPrefs::gfx_font_list_omt_enabled_AtStartup() &&
      StaticPrefs::gfx_e10s_font_list_shared_AtStartup() &&
      !gfxPlatform::InSafeMode()) {

    MOZ_CRASH("HELLO, THIS IS GOING TO CRASH");

    sInitFontListThread = PR_CreateThread(
        PR_USER_THREAD, InitFontListCallback, aList, PR_PRIORITY_NORMAL,
        PR_GLOBAL_THREAD, PR_JOINABLE_THREAD, 0);
    return true;
  }
  if (aList->InitFontList()) {
    return true;
  }
  Shutdown();
  return false;
}

Here's a startup profile of this modified build: https://share.firefox.dev/3vw311f if it's any useful. I still see some loading of Segoe and Times, but they only hang for a bunch of milliseconds.

Comment 1

[Jonathan Kew [:jfkthame]]

Rather than hacking at the code, you could try just setting gfx.font-list-omt.enabled to true in about:config and see how this affects your startups; that pref is false by default on all platforms except macOS at present:
https://searchfox.org/mozilla-central/rev/97c902e8f92b15dc63eb584bfc594ecb041242a4/modules/libpref/init/StaticPrefList.yaml#5459-5466

If you experiment with that, I'd be interested to know how it goes. Back when that code was implemented, I wasn't seeing significant benefit from it on my Windows machine, but perhaps things are different now (or different on your system, for some reason).

Comment 2

[clessili]

It didnt seem to do much. Here's a profile with it enabled: https://share.firefox.dev/3LmIel8
I wonder if it's simply something wrong with my install of Windows, as I don't know how to reproduce it but it's present even on completely fresh installs of firefox.

Comment 3

[Jonathan Kew [:jfkthame]]

It looks like a single call in to dwrite.dll (DWriteFactory::GetSystemFontCollection) is taking over a second in the "privileged content" process. That's pretty terrible. But I don't know what we can do about it; we have to get the font collection from DirectWrite before we can do any layout or rendering that involves text, whether for the Firefox UI or for web content. And it shouldn't normally take such a long time. I just profiled a startup on my Windows 10 machine and it shows that call taking 2ms, which is far more reasonable.

My guess is that this is somehow related to a caching failure in DirectWrite; I think it's supposed to cache lots of information about the installed fonts, but if this fails (or for some reason it thinks the cache needs to be rebuilt from scratch), then the first call to DirectWrite ends up taking a hugely long time while that happens. But I don't know why this would be happening on your system. I can understand DW needing to rebuild its caches if, for example, a system update has installed new versions of some fonts. But that should be a one-time operation; it shouldn't have to keep happening on every launch.

Comment 4

[Daniel Bodea [:danibodea]]

Is this a regression? Did it start occurring only in the last period of time?
Or did it start occurring after you changed something to your hardware?
What sort of pages are you restoring to see this issue reprosuce? Does it happen in the case of restoring ANY webpage?

Thanks!

I have to say that my Windows 10 seems to reload a session or a tab really fast so I think I'm not reproducing it, or maybe IO haven understood the exact steps to reproduce it.

Comment 5

[clessili]

Attachment: pause before the first and second tabs start loading

Comment 6

[clessili]

I think it happens since I first installed firefox on my current computer, around december 2019. I remember thinking "wow Firefox is fast to boot on this, too bad it takes 3 extra seconds before it starts loading a page".

I couldn't get an exact regression range, at some point it was unclear whether the page was just slow to restore because of the network (it kept loading https://support.mozilla.org/en-US/kb/how-change-your-default-browser-windows as the first tab), but it seemed to get slower around the Australis era. Also in one of those versions, opening a New Window showed the slow loading but opening a "New Non-e10 window" didn't.

In the current Firefox, it happens when restoring the first tab (or before drawing the homepage if firefox doesn't have "Open previous windows and tabs" checked), and when restoring some of the other tabs, but not all.

Maybe my install is just botched. If it's nearly impossible to reproduce, don't bother, I'll be back when/if I do a clean reinstall and the problem persists.

Comment 7

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Bas Schouten (:bas.schouten)]

The Performance Priority Calculator has determined this bug's performance priority to be P3. If you'd like to request re-triage, you can reset the Performance flag to "?" or needinfo the triage sheriff.

Platforms: Windows
Impact on browser UI: Causes noticeable startup delay
Configuration: Specific but common

Comment 9

[Daniel Bodea [:danibodea]]

QA could not reproduce this issue. If this issue is reproducible after a clean install (as mentioned in comment 6), please offer clear steps to reproduce it, in order to confirm it. Thank you for your contribution!

Comment 10

[Wayne Mery (:wsmwk)]

Incomplete per comment 9.