alacritty: Slow to draw initial window, time spent in FcFontMatch

Which operating system does the issue occur on? Arch Linux If on linux, are you using X11 or Wayland? X11

Here’s a brief screen capture of the issue: https://jon.thesquareplanet.com/share/alacritty-slow-start.mp4

Running it through callgrind, I get a profile that points pretty squarely at FcFontMatch being the culprit. Sadly, bumping the fontconfig and freetype dependencies doesn’t fix the issue (#1602).

Any suggestions for what to try next? Has anyone else seen a similar issue?

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 21 (21 by maintainers)

Most upvoted comments

Yeah, I’ll open a new issue if I discover that the external screen makes a difference.

Digging through, I get these primary call chains (probably incomplete due to inlining):

(Display::new + Display::handle_resize + Display::draw) -> FreeTypeRasterizer::get_glyph -> FcFontMatch
(Display::new + Display::handle_resize) -> GlyphCache::compute_font_keys -> FreeTypeRasterizer::load_font -> FcFontMatch

If I disable inlining on all GlyphCache methods, I get that the calls are coming from GlyphCache::new, GlyphCache::update_font_size (through Display::new and Display::handle_resize respectively). It looks like there are just many repeated (and unnecessary?) calls to FcFontMatch indirectly through the GlyphCache methods, when in reality those calls could probably all be reduced to a single one. My current profiles suggest that that could possibly be near a 10x speedup for startup.

jonhoo on Sep 29, 2018

Filed tomaka/glutin#1070

jonhoo on Oct 1, 2018

I’d like to keep discussions on this issue in #782, however this looks like a different problem which is not due to an issue with Alacritty, but a problem with glutin.

I’d recommend to test if this is reproducible with the glutin examples and report it upstream if it is.

chrisduerr on Oct 1, 2018

Thanks for looking into this. After the big speed improvement with dynamic allocation for large scrollback sizes, further improving Alacritty’s boot time would really be nice.

If you want to take a stab at resolving this issue and have any questions, please let me know.

chrisduerr on Sep 29, 2018

Okay, I’d then suggest changing the purpose of this issue from solving a bug, to improving startup performance by reducing the FcFontMatch calls. The title seems fine to me, just going to add some tags.

If there’s any actual buggy behavior, it should be tracked in a different issue.

Edit: It would also be interesting to see how this performs on Alacritty, since FcFontMatch should not exist there. If this is glyph-cache related, it might be the same just with a different function call, but it definitely seems to be worth investigating.

chrisduerr on Sep 29, 2018

Oops, I missed the gif.

jwilm on Sep 28, 2018