Affected versions

• Firefox 83.0b6
• Firefox 84.0a1

Affected platforms

• Ubuntu 18.04 & 20.04

Steps to reproduce

1. Launch Firefox
2. Access Wikipedia
3. Zoom in / out

Expected result

• The zoom is snappy

Actual result

• The zoom has a high latency

Regression range

• I will see for a regression.

Additional notes

• The issue can be seen in the attachment
• Windows seems to be not affected, and macOS was affected and fixed by Bug 1657892.

Suggested severity

• S3

Is it possible to get a profile?

Sure thing Sean, hope this helps: https://share.firefox.dev/2JTIdeB . First time scrolling it literally freeze for about 4-5 seconds or something, then it scrolled again.

Hi,
I did a mozregression on Ubuntu 18. I based myself on whether the Wikipedia's globe photo on the top left corner got glitchy or not. Here's the pushlog. I hope it helps and that my analysis was right: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a5cb1a40413ebfb37e68bc8961e5a46467f06d14&tochange=d44e2877a9b3d696cc301b44255f9ed9f960009a

Rregards, Flor.

Thanks Flor and Catalin! Looks like bug 1644271 is a likely regressor. Will move this to APZ for now to see if the team has any ideas based on the profile.

As with bug 1657892 the profile seems to indicate a lot of time spent in font code. It's likely the Linux equivalent of bug 1657892. Jonathan, can you take a look?

There's a huge amount of time being spent in fontconfig code called under gfxFontconfigFontEntry::CreateFontInstance. I think we need to investigate whether (a) a few font-instantiations are taking an excessively long time for some reason, or (b) a huge number of different font instances are being created (rather than the same font instances getting re-used from cache). If I can reproduce this locally, I can probably instrument the code a bit to get a clearer idea of what's happening here.

(One thought: I guess with pinch-zoom it's possible that we are instantiating fonts at a huge number of fractionally-different sizes, and this is hurting here. Perhaps we need to quantize font sizes so that we don't end up creating an almost-infinite number of instances with imperceptible size differences.)

Oh, this wasn't about pinch-zoom performance, just "normal" page zoom. So the last thought above isn't relevant here.

I tried profiling my Ubuntu 18.04 machine with Nightly, zooming the wikipedia.org page in and out. My reflows are not nearly as long as shown in the profile from comment 2 (I get reflows of around 300ms rather than 1 second-plus), but that may just be a machine difference; it's still a lot slower than we'd like.

By far the majority of the time is being spent within fontconfig functions, called from gfxFontconfigFontEntry::CreateFontInstance when we need to instantiate a gfxFont for a given font resource/size/style. Maybe we should try to reduce our dependency on fontconfig APIs and instead work more directly just with freetype faces. (This may be tricky, though, if we want to properly respect arbitrary things that may have been set in the user's fontconfig configuration.)

The other question I wondered is whether we're instantiating too many different fonts, or failing to use the font cache properly. I was shocked at how many separate instances we're creating from the same font entry, with the same size, each time the page is zoomed. But on looking into the page, it makes sense: the "problem" arises because wikipedia.org has tagged all the links to different-language wikis, and even each item in the search-field language menu, with its own individual lang="..." attribute. This results in instantiating a separate font for each of those elements, because it's possible for language to affect font rendering and so we can't simply instantiate a "generic" font and use it across all the differently-tagged elements.

So this wikipedia home page is kind of a pathological case, where even though most of the content appears in the same default sans-serif font, we end up instantiating dozens (maybe hundreds?) of copies of it. If we could get away from doing that, and find an alternative way to manage language-specific font rendering, we'd see a big win here.

This is primarily an issue on Linux because of how expensive the fontconfig calls are; instantiating separate gfxFonts for each language on other platforms is cheap enough that it barely shows up in a profile.

Moving this to Graphics: Text as it's primarily about the management of font instances within gfx/thebes. We can get a substantial improvement by splitting out the language field from gfxFontStyle so that it doesn't cause multiplication of font instances, and instead passing language through separately to the shaping etc operations that need it, while using the same font instance.

This allows us to avoid instantiating separate gfxFont objects when content is tagged
with different 'lang' attributes, yet ends up using the same fonts (e.g. Wikipedia may
use a default font such as Arial for language names/links that are tagged with several
dozen different languages).

Catalin, there's a tryserver build at https://treeherder.mozilla.org/jobs?repo=try&revision=fbe24426edd5b219e057f75688839632ac863a66&selectedTaskRun=Igp_OlNZRamqfibgwFCcCA.0 if you'd like to try it and check that it improves this wikipedia-reflow case.

Hey Jonathan, I just got for a spin the "try-build" and the zoom reaction for the browser is just perfect. It was tested on Ubuntu 20.04. Here's a short video about it.

https://hg.mozilla.org/mozilla-central/rev/98ae69287e9e

Reproduced the issue with Firefox 84.0a1 (20201030213850) on Ubuntu 18.04. The zoom was snappy when following the STR from comment 0.
The issue is verified with Firefox 84.0b3 (20201119195818) on Ubuntu 18.04. Zooming is way smoother than on the affected build.