1542314 - font related timers seem to run relatively often even on an idle browser

Status: NEW

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

Description

[Olli Pettay [:smaug][[e-mail]]]

I'm looking at what all causes wake ups, and at least in the parent process font related timers seem to fire relatively often, even if browser is otherwise rather idle.

https://searchfox.org/mozilla-central/rev/9ee63566281365f26e7a4b06c9d4e2219e64c3e8/gfx/thebes/gfxFcPlatformFontList.cpp#1389-1393
https://searchfox.org/mozilla-central/rev/9ee63566281365f26e7a4b06c9d4e2219e64c3e8/gfx/thebes/gfxFont.cpp#192-196

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

In fact, they seem to be the only timers running all the time, if the browser is otherwise idle
(it takes quite a bit time after startup before browser really is idle).

Comment 2

[Jonathan Kew [:jfkthame]]

These are two unrelated timers, and if we want to change anything about them, we should probably consider them independently.

(1) https://searchfox.org/mozilla-central/rev/9ee63566281365f26e7a4b06c9d4e2219e64c3e8/gfx/thebes/gfxFcPlatformFontList.cpp#1389-1393

This (Linux-only) timer is how changes in the font configuration are picked up, so that newly-installed fonts can start being used by content where appropriate. It would be nice if we could instead just get a notification from fontconfig when something has changed, but I don't know of any such mechanism.

Perhaps we could consider checking for font configuration changes on certain specific events instead of periodically. Checking at the start of every reflow might be too expensive, but perhaps we could check on window activation events, or something like that.

(2) https://searchfox.org/mozilla-central/rev/9ee63566281365f26e7a4b06c9d4e2219e64c3e8/gfx/thebes/gfxFont.cpp#192-196

This is currently enabled only on dev builds (it's guarded by #ifndef RELEASE_OR_BETA), and fires once per minute. Its purpose is to "expire" cached data that has not been recently used, to reduce memory footprint. Maybe we could arrange to turn it off once the relevant caches are empty, so that it doesn't keep firing if the browser is idle for an extended time.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 4

[Lee Salzman [:lsalzman]]

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

These are two unrelated timers, and if we want to change anything about them, we should probably consider them independently.

(1) https://searchfox.org/mozilla-central/rev/9ee63566281365f26e7a4b06c9d4e2219e64c3e8/gfx/thebes/gfxFcPlatformFontList.cpp#1389-1393

This (Linux-only) timer is how changes in the font configuration are picked up, so that newly-installed fonts can start being used by content where appropriate. It would be nice if we could instead just get a notification from fontconfig when something has changed, but I don't know of any such mechanism.

Perhaps we could consider checking for font configuration changes on certain specific events instead of periodically. Checking at the start of every reflow might be too expensive, but perhaps we could check on window activation events, or something like that.

It looks like the fontconfig rescan interval is determined by fontconfig cfgs on the distro, and that on my machine, for instance, it is configured to 30 seconds. Do we want to set a sane floor for that to something like a minute? i.e. max(1min, rescanInterval)

Comment 5

[Jonathan Kew [:jfkthame]]

I'm not sure setting a rescan interval floor gains us all that much, unless it's a really long interval - which could impact usability in that a newly-installed font might take a very long time to become available. But a reasonably short interval such as a minute is still much to frequent to be waking up an otherwise-idle browser.

What about the idea of checking for changes on key events in the browser that are generally correlated with user actions (and won't be happening if the browser is idle)? I'm thinking things like page load and window activation: if we checked for fontconfig changes on these events, we'd pick up any updates in time to use them when it matters, yet we wouldn't need to wake up an idle browser just for a periodic check.

Comment 6

[Lee Salzman [:lsalzman]]

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

I'm not sure setting a rescan interval floor gains us all that much, unless it's a really long interval - which could impact usability in that a newly-installed font might take a very long time to become available. But a reasonably short interval such as a minute is still much to frequent to be waking up an otherwise-idle browser.

What about the idea of checking for changes on key events in the browser that are generally correlated with user actions (and won't be happening if the browser is idle)? I'm thinking things like page load and window activation: if we checked for fontconfig changes on these events, we'd pick up any updates in time to use them when it matters, yet we wouldn't need to wake up an idle browser just for a periodic check.

What would seem to be the downside of that is then we are moving CPU usage and file IO to the times when those are already just going to be spiking?

Comment 7

[Jonathan Kew [:jfkthame]]

True; though in the usual case we'd just make two calls, FcInitBringUptoDate() and FcConfigGetCurrent(), which I would guess (but have not instrumented to check -- should do!) are extremely cheap in the 99.999% of cases where nothing has actually changed. So my gut feeling is that the impact would be negligible. Could be wrong about that, though.

(I'm assuming that with the current rescan timer, the actual work we do each time is basically negligible, but the problem is that we're constantly waking up the browser when it could otherwise be completely idle. With the user-initiated event model, the browser has been woken up to do something anyhow, at which point I suspect the fontconfig check won't be noticeable.)

Comment 8

[Jonathan Kew [:jfkthame]]

I checked on my Linux laptop, and currently it takes just under 0.5ms, on average (varying between about 0.3ms and 0.8ms), to call FcInitBringUptoDate() and FcConfigGetCurrent() and conclude that there's nothing further to do. So that gives an idea of the overhead we'd be adding to events like window activation if we did the check for fontconfig changes there instead of on a timer.

Comment 9

[Lee Salzman [:lsalzman]]

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

I checked on my Linux laptop, and currently it takes just under 0.5ms, on average (varying between about 0.3ms and 0.8ms), to call FcInitBringUptoDate() and FcConfigGetCurrent() and conclude that there's nothing further to do. So that gives an idea of the overhead we'd be adding to events like window activation if we did the check for fontconfig changes there instead of on a timer.

So if I understand correctly it would have to behave like this to give the expected behavior:

If the browser is idle, we delay doing any checks.
When the browser "activates" from some event, if we delayed checking, then we do an immediate check if the last check was longer ago than the check interval.
And then while the browser is not idle yet, we do checks on the normal interval so that and further changes that may take place to the font config get picked up.