1439412 - Linux: Evaluate only using fontconfig in the parent process

Status: NEW

(Core :: Graphics: Text, enhancement, P3)

Description

[Randell Jesup [:jesup] (needinfo me)]

Chrome uses fontconfig for matching and opening font files only in the 'browser' process; renderers send match requests (and open requests) over IPC.  This involves more CPU overhead, especially in some cases, but probably would save us around 1MB in each Content process.

We'd have to remote HandleGetFallbackFontForChar()

Chrome's code is in content/browser/sandebox_ipc_linux.cc, content/common/font_config_ipc_linux.cc (renderer side), and content/browser/renderer_host/font_utils_linux.cc

This would be important for site-isolation work

See numbers in bug 1436250 comment 1 and 6

Comment 1

[Eric Rahm [:erahm]]

P3 for now as this is only linux.

Comment 2

[Tom Ritter [:tjr]]

This wouldn't move font *parsing* into the parent process though, right?

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Tom Ritter [:tjr] from comment #2)
> This wouldn't move font *parsing* into the parent process though, right?

My understanding is that this is about system fonts, not Web fonts.

Comment 4

[Eric Rahm [:erahm]]

The lower bound on this seems to be 500k per content process (that's just grepping heap-unclassified for libfontconfig on a DMD build run). Bumping priority due to the impact on content process overhead.

Comment 5

[Eric Rahm [:erahm]]

A DMD run with full stacks puts it around 1.7MB unreported and 50k reported in 'font-list'.

Comment 6

[Eric Rahm [:erahm]]

kmag noted 8MB per content process on Arch; he had ~1785 local fonts installed. It seems like 2MB is more of a lower bound.

Comment 7

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

FYI, our current workaround for the sandboxing implications of fontconfig-in-content involves filtering the font list through the sandbox policy and passing it down when starting content processes; see bug 1412090.  I suspect that this might be causing the process launch delays reported in bug 1468889, but I can't reproduce that locally and it's not clear if the main problem there is actually font-related.

However, inspired by that bug, I tried profiling with the official Nightly build, and I see up to 80ms spent blocking the parent process main thread in fontconfig for every content process launch.

I do have ~4x as many fonts on this machine as stock Ubuntu 16.04 with en_US locale (1075 vs. 257, measured by `fc-list | wc -l`; note that the number of distinct font files, `fc-list : file | wc -l`, is slightly lower), so the average or nth-percentile Firefox user may be seeing less delay.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #7)
> I do have ~4x as many fonts on this machine as stock Ubuntu 16.04 [...] so the
> average or nth-percentile Firefox user may be seeing less delay.

Given that ^ and that this is Linux-only, I think this isn't in-scope for QF prioritization -- marking qf-. (Don't let that discourage anyone from working on this, though!)

Comment 9

[Kris Maglione [:kmag]]

I believe that this is a problem even for users with a standard number of fonts, we just don't have numbers for those yet.

Also, I think ideally we'd want to do this in a way that works for all platforms. The problem just seems to be the worst on Linux

Comment 10

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

David - as we discussed, fonts use a lot of memory, especially on Linux. This will likely be a blocker for Fission on Linux if we can't find a way to ameliorate the issue.

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

Lee would this be something you or jfkthame would own?

Comment 12

[Karl Tomlinson (:karlt)]

https://bugzilla.mozilla.org/show_bug.cgi?id=1416177#c11

Comment 13

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I notice I didn't attach a profile in comment #7, so here's one from that machine but in a clean browser profile:
https://perfht.ml/2LtMjpD

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Given comment 9, I think it's worth upgrading this to a qf:p3.

Comment 15

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧ from comment #7)
> I see up to 80ms spent blocking the parent process main thread in
> fontconfig for every content process launch.
> 
> I do have ~4x as many fonts on this machine as stock Ubuntu 16.04 with en_US
> locale (1075 vs. 257, measured by `fc-list | wc -l`; note that the number of
> distinct font files, `fc-list : file | wc -l`, is slightly lower), so the
> average or nth-percentile Firefox user may be seeing less delay.

We have Telemetry on this now.  (See also bug 1474991.)  Comparing CONTENT_PROCESS_LAUNCH_MAINTHREAD_MS on Linux vs. Windows/Mac, the median time spent blocking the main thread is ~40ms higher, and from what I've seen in profiling it's not a huge stretch to ascribe all of that difference to our current workaround for not having remote fontconfig.

The 80ms delay I observed looks like about the 80th percentile on Nightly and the 75th percentile on Beta.

Comment 16

[Eric Rahm [:erahm]]

Pretty sure this is being worked on in bug 1514869.

Comment 17

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Eric Rahm [:erahm] (ni? for phab reviews) from comment #16)

Pretty sure this is being worked on in bug 1514869.

According to Jonathan Kew [:jfkthame] in an email thread that's been going on, the current work would share data to save memory but at least in some cases content processes will still need to access the OS font APIs directly. I don't know offhand how the main thread jank problem on Linux would be affected.

Comment 18

[[e-mail]]

It was suggested that this might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1468889 If so I'm hoping this fix can reach the next Firefox version and close that as well.

I experience a roughly 1 second delay whenever opening a new tab, if my number of existing tabs is lower than the maximum number of processes Firefox may spawn. The analysis I submitted at the time suggested this might be related to libfontconfig.

Comment 19

[Andrew McCreight [:mccr8]]

Eric, is the memory part of this mostly solved now due to bug 1514869? Can we downgrade this for MemShrink (and put a MemShrink:P1 tag on the other bug) or remove it entirely?

Comment 20

[Eric Rahm [:erahm]]

(In reply to Andrew McCreight [:mccr8] from comment #19)

Eric, is the memory part of this mostly solved now due to bug 1514869? Can we downgrade this for MemShrink (and put a MemShrink:P1 tag on the other bug) or remove it entirely?

I'm not totally sure, there might be paths where we load fontconfig in the content process which could be problematic. Jonathan, is there still work to be done here or are things as good as they're going to get?

Comment 21

[Jonathan Kew [:jfkthame]]

Note that the shared-memory implementation from bug 1514869 is not yet preffed-on, so unless you explicitly add gfx.e10s.font-list.shared=true to about:config, you won't see the effect of it.

There's also work to be done (bug 1552941) to enhance the fontconfig integration; how much of that will need to run in the content process, and how much can be pushed into the parent, is not completely clear to me yet. So it's possible some of the wins we get when bug 1514869 is preffed on might be partially reversed there.

So - bug 1514869 (when preffed on) should give a noticeable win, but this may not be the end of the story. Work still ongoing.