Affected versions

• Firefox 80.0b5
• Firefox 81.0a1

Affected platforms

• macOS 11 (public beta 1)

Steps to reproduce

1. Launch Firefox
2. Access for example Wikipedia
3. Zoom the page by touchpad or by mouse wheel

Expected result

• Zooming in page is snappy

Actual result

• Zooming lags behind user interaction

Regression range

• I don't think this is a regression

Additional notes

• The issue can be see in the following attachment

Can you get a Gecko performance profile for this? Thanks!

Hey Kartikaya, I can't seem to be able to publish the recordings on nightly because as soon as I click on publish, the tab will crash. I was able to publish it in 80.0b5 (https://share.firefox.dev/2C7Jhb7)

At first glance the profile shows a lot of time being spent in font-related code. Maybe they changed some APIs in Big Sur? Moving to font component.

Also cc mstange as a "this may be relevant to your interests"

The profile doesn't seem to have nearly the detail I would expect. Can you re-profile with the "Firefox platform" profiler options (if that's not what was already used here)? Thanks.

That's what I used, and on 81.0a1 while trying to publish, I only get a tab crash, and did one with the profiler and "Firefox platform" from 80.0b5. Please let me know if I can help with any other info.

That's weird. I'd expect there to be lots of layout-related frames in between PresShell::DoFlushPendingNotifications and anything font-selection-related like gfxFontGroup::SearchAllFontsForChar. Any thoughts on what's up with this profile, :kats?

I'm guessing the symbolication is broken. Markus probably has a better idea of how to fix this.

Catalin filed bug 1657917 for the profiler problem.

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

That's weird. I'd expect there to be lots of layout-related frames in between PresShell::DoFlushPendingNotifications and anything font-selection-related like gfxFontGroup::SearchAllFontsForChar.

On macOS the profiler cannot obtain C++ stacks in Firefox Beta builds, because Firefox Beta is compiled without frame pointers (bug 1451902).
So it's either "no profile" or "useless profile" for now... :-(

I think the crash might be fixed in the latest Nightlies. Could you try to get a profile from Nightly again?

This doesn't seem to be macOS 11 specific. I can reproduce really laggy reflow zoom on that site on macos 10.15

How laggy do you mean? I'm seeing reflows of usually around 40-50ms here, which is more than we'd like but a lot better than the hundreds of ms in the profile in comment 2.

160ms reflows, seems like one for every zoom step. Once we've reflowed at each zoom step the reflows get a lot faster. This is on 16" 2019 macbook pro.

Ah, it looks like instantiating fonts for each new size is unpleasantly expensive. Once they're in our cache, things get substantially better.

In particular, looking up the font's variation axes via Core Text in order to configure variation values seems to be costly. I think we can improve things by caching the variation axis information in UnscaledFontMac.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=fb1a72077378417fff0b8f7ec99c56bedbff8716

https://hg.mozilla.org/mozilla-central/rev/80da3bcb8ef3

Yep, it seems that the tab crash in 81.0a1 (2020-08-09) is fixed, but the reflow is still happening on wiki. Will verify it when the fix will arrive to nightly.

The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment on attachment 9168986 [details]
Bug 1657892 - Cache variation axes in the UnscaledFontMac to accelerate font instantiations. r=lsalzman

Beta/Release Uplift Approval Request

• User impact if declined: Laggy reflows, particularly when zooming in/out on a page that uses lots of different fonts (e.g. because of mixed languages)
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Straightforward patch to cache some details needed during font instantiation, to avoid calling expensive macOS APIs every time. Patch is in mac-only code, cannot affect other platforms.
• String changes made/needed:

Although this isn't a recent regression, IMO the patch is simple enough and the benefit sufficiently worthwhile that we should consider uplift here.

Removing link to the Big Sur support meta-bug (bug 1648487) as this isn't specific to the new OS version.

Is there a potential impact on memory use?

Not really; the size of the data being cached is pretty insignificant.

Comment on attachment 9168986 [details]
Bug 1657892 - Cache variation axes in the UnscaledFontMac to accelerate font instantiations. r=lsalzman

good to know, thanks.

approved for 80.0b8

https://hg.mozilla.org/releases/mozilla-beta/rev/d993e4849f47

Hei Jonathan, it seems that the reflow is still happening. This is an attachment from 80.0b8, the same goes for Firefox 81.0a1 (2020-08-16). This was reproduced on macOS 11 (public beta 1).

Any idea of what happened? Please let me know if I can help with anything else.

Could you get a profile for this, please?

Sure thing. Here it is: https://share.firefox.dev/2CzbY0R

Thanks. So (assuming this is the same system & page as the profile from comment 2), it is somewhat improved: I see reflows of around 270ms, whereas previously they were around 350-380ms. Still laggy but not quite as bad.

For comparison, could you please try enabling gfx.e10s.font-list.shared in about:config (and restart the browser), and then post a new profile with that setting? Thanks again!

Ok. After changing the pref, it was a bit laggy, but better than the situation from comment 2, and after a couple of seconds, it went smoothly. Here's the profile https://share.firefox.dev/2DQhGMH

Looks quite a bit better, yes. Those early reflows are down to around 100ms, which is still a bit laggy but considerably less than before.

I'm hoping to enable that pref by default soon, so that should help the situation here.

One more thing: I've pushed a try build with an experimental patch that may help further. Could you please re-test with the "shippable opt" build from https://treeherder.mozilla.org/#/jobs?repo=try&selectedTaskRun=IlnyVXBkSjej7_U7JAHNiw.0&revision=ddae9085ed781da80c7b9f48da34bc7d2a33bf84 and see how that compares (without setting the font-list.shared pref)? Thanks.

Sure thing, I was on 10.15.6 this time. Tried with the try build, and it works as if the pref was active, a bit laggy a couple of seconds, then smoothed out.

OK, thanks -- sounds like it's worth taking that patch. I'll spin it off into a separate bug for easier tracking.

Verified fix on bug 1659453 and seems that Firefox 81.0a1 (2020-08-19) zooms correctly the wiki page.

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

I'm hoping to enable that pref by default soon, so that should help the situation here.

Verified with 80.0:

• on macOS 10.15 it works ok;
• on macOS 11.0, works properly only with gfx.e10s.font-list.shared set on true; in default state it's still laggy.

In regards to this, is it safe to mark the issue as verified or add the tracking-bug for the pref-flip to default as a blocker to this?

I think we can consider this verified-fixed. It's always possible that OS changes (like going from 10.15 -> 11.0) will again affect performance here because of changes in the system fonts, and we may need to update some heuristics accordingly, but we should just file new issues about that if/when it happens.