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
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.
Most helpful comment
I've narrowed it down even more, there is this very funny font
Adobe Blankwhichmaps 1,111,998 Unicode code points to 2,048 non-spacing and non-marking glyphs. After I filter it fromgoogle-fontsderivation, everything becomes snappy again. ((setf face-ignored-fonts '("Adobe Blank"))also works). Maybe it'd be a good idea to filter it out fromgoogle-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=1env 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
fontconfigfrom master are noticeable, but only for synthetic cases likedescribe-font.view-hello-fileand files I'm working on (xml with translations to a lot of different languages) works perfectly fine even with stock nixpkgs version.