Nixpkgs: Fontconfig 2.13 without recent patches makes parts of Emacs unusable

Created on 27 Oct 2020  路  16Comments  路  Source: NixOS/nixpkgs

Describe the bug
Searching for fonts matching a pattern has become incredibly slow; we're talking like, 20+seconds; as Emacs tries to match for fonts in real-time, it has rendered it effectively unusable (for example, M-x describe-fontset RET RET). Commits to fontconfig's master branch in late August, 2020 have greatly improved matters greatly.

Specifically, the commits by Matthias Clasen in August 2020: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commits/master/

Please include these performance fix commits as patches.

Additional context
The specific emacs behaviour occurs on my NixOS system, but not my Ubuntu + Nix system.
Notify maintainers
@vcunat

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: fontconfig
# a list of nixos modules affected by the problem
module: fonts.fontconfig
bug

Most helpful comment

I've narrowed it down even more, there is this very funny font Adobe Blank which maps 1,111,998 Unicode code points to 2,048 non-spacing and non-marking glyphs. After I filter it from google-fonts derivation, everything becomes snappy again. ((setf face-ignored-fonts '("Adobe Blank")) also works). Maybe it'd be a good idea to filter it out from google-fonts, at least by default - from https://blog.typekit.com/2013/03/28/introducing-adobe-blank/ is seems that web is primary use case, and I see little reason to have this font installed system-wide.

I've discovered this by running emacs with FC_DEBUG=1 env variable, the insanely long list of covered characters starts to be immediately noticeable - even printing debug information takes a lot of time.

And BTW, performance improvements from using fontconfig from master are noticeable, but only for synthetic cases like describe-font. view-hello-file and files I'm working on (xml with translations to a lot of different languages) works perfectly fine even with stock nixpkgs version.

All 16 comments

Thanks for your report @spacekitteh, we can do this

So the issue is from the last unstable release to now is 79 commits https://gitlab.freedesktop.org/fontconfig/fontconfig/-/compare/2.13.92...master, I assume you only mean the patches by Matthias Clasen in that range fix the issue?
I almost feel... like we should use fontconfig master on unstable. We should however have those patches from Matthias Clasen and ~others?~ as well for memory leaks on stable. cc @jtojnar

I'm fine with using master, but I'm just a user, not a maintainer!

I'm fine with using master, but I'm just a user, not a maintainer!

I meant we would use fontconfig master. This should be fixed in whatever way that's appropriate on the supported channels.

I'm fine with using master, but I'm just a user, not a maintainer!

I meant we would use fontconfig master. This should be fixed in whatever way that's appropriate on the supported channels.

Yes, that's what I meant :)

I guess it's a little risky that we're using an unstable version of fontconfig. (since PR #73795)

Is there any movement on this?

I've tried doing it with fontconfig from master, but it didn't help. I gave up on view-hello-file after 10 minutes. Here is how I have consumed fontconfig:

pkgs-fc = import <nixpkgs> {
  overlays = [];
  config.packageOverrides = super: {
    fontconfig = super.fontconfig.overrideAttrs (oldAttrs: {
        name = "fontconfig-patched";
        src = pkgs.fetchFromGitLab {
          domain = "gitlab.freedesktop.org";
          owner = "fontconfig";
          repo = "fontconfig";
          rev = "b2a54dfb8fe3859cf8c7f1d1d9b43318ef2a0ca3";
          sha256 = "1a39zq24965gpc4myvfcy725wwpx93mwi64ngara6yj21vma58b3";
        };
        patches = []; # All patches are merged already

        # This test uses `curl` to reach external world
        postBuild = ''
          chmod -x test/test-crbug1004254
        '';

        # It's needed now
        buildInputs = oldAttrs.buildInputs ++ [ pkgs.python3 ];
      });
  };
};

Even with unpatched fontconfig things started to work normally after I've removed google-fonts from my NixOS configuration. There are 22 more font packages installed, and only this one was driving emacs mad.

Maybe the number of fonts is the problem, as google-fonts contains ~2800 fonts, while other packages in my list only contribute ~1000.

I've narrowed it down even more, there is this very funny font Adobe Blank which maps 1,111,998 Unicode code points to 2,048 non-spacing and non-marking glyphs. After I filter it from google-fonts derivation, everything becomes snappy again. ((setf face-ignored-fonts '("Adobe Blank")) also works). Maybe it'd be a good idea to filter it out from google-fonts, at least by default - from https://blog.typekit.com/2013/03/28/introducing-adobe-blank/ is seems that web is primary use case, and I see little reason to have this font installed system-wide.

I've discovered this by running emacs with FC_DEBUG=1 env variable, the insanely long list of covered characters starts to be immediately noticeable - even printing debug information takes a lot of time.

And BTW, performance improvements from using fontconfig from master are noticeable, but only for synthetic cases like describe-font. view-hello-file and files I'm working on (xml with translations to a lot of different languages) works perfectly fine even with stock nixpkgs version.

Hmm, interesting - I have indeed added Adobe Blank, but I was sure I only added it to try and resolve the aforementioned slowdown. I wasn't aware it was included in google-fonts. I'll try it out ASAP!

I was stuck on this for 3 days. I can confirm that removing google-fonts fixed the issue...

Tracking the issue from gdb to here was so painful. So happy, I can sleep now.

Hey uninstalling google-fonts also fixed a startup crash that I have had for over a month with thunderbird.

If anybody else is struggling with a thunderbird issue that might be it.

Ideally, we would also try reproducing it on another Linux distro with recent enough fontconfig (Arch/Manjaro VM) and possibly reporting it upstream. Though I guess removing the font for now is probably fine as the font has limited usefulness.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40733#65 - it's reproducible on Arch/Manjaro by manually installing that font. And Arch is not installing it as a part of its google-fonts.

I have #103779 open which fixes the issue. It just moves AdobeBlank-Regular.ttf to a separate output ( google-fonts.adobeBlank ).

I took a look at fontconfig and it's seems like the deeper issue is that there is a really inefficient search system for font families and fallback symbols; but that's a can of worms that is harder to solve.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rzetterberg picture rzetterberg  路  3Comments

copumpkin picture copumpkin  路  3Comments

sid-kap picture sid-kap  路  3Comments

edolstra picture edolstra  路  3Comments

lverns picture lverns  路  3Comments