[SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

loserMcloser · 2025-12-30 15:48:31

For the past couple of weeks (not sure when it started), opening/displaying a PDF within chromium causes the chromium process to go up to ~95% for close to 30 seconds before the PDF is displayed. (Before that just the dark grey background that chromium usually uses for PDFs.)

Anyone know what this might be about?

Last edited by loserMcloser (2026-01-23 17:09:21)

seth · 2025-12-30 18:12:18

Do you get this w/ a fresh user or profile?
Maybe some extension interfering?

loserMcloser · 2025-12-30 22:21:38

seth wrote:

Do you get this w/ a fresh user or profile?
Maybe some extension interfering?

Yes, tried with a fresh user and still happens. I also have no chromium extensions installed under my usual user/profile.

seth · 2025-12-30 22:49:43

Any PDF, eg. /usr/share/cups/data/default-testpage.pdf ?
Are other electron-based browsers like vivaldi affected the same?
Is mupfd?

pacman -Qikk chromium

is from the repos and not a flatpak etc?
Do you have an excessive amount or weird fonts installed?

loserMcloser · 2025-12-30 23:21:59

seth wrote:

Any PDF, eg. /usr/share/cups/data/default-testpage.pdf ?

Yes, any PDF.

seth wrote:

Are other electron-based browsers like vivaldi affected the same? Is mupfd?

Is vivaldi electron-based? I don't see electron in its list of dependencies. In any case, I temporarily installed it, and PDFs opened instantly in it. Firefox and mupdf also open PDFs instantly.
Also don't have any issue viewing PDFs from within vs code (for example, when editing LaTeX and viewing the built PDF).

seth wrote:

pacman -Qikk chromium
is from the repos and not a flatpak etc?

Yes, installed from the repos, not a flatpak.

# pacman -Qikk chromium
Name            : chromium
Version         : 143.0.7499.169-1
Description     : A web browser built for speed, simplicity, and security
Architecture    : x86_64
URL             : https://www.chromium.org/Home
Licenses        : BSD-3-Clause
Groups          : None
Provides        : None
Depends On      : gtk3  nss  alsa-lib  xdg-utils  libxss  libcups  libgcrypt  ttf-liberation  systemd  dbus  libpulse  pciutils  libva  libffi  desktop-file-utils  hicolor-icon-theme  fontconfig  brotli  libjpeg-turbo  flac  libxml2
                  libwebp  minizip  opus  harfbuzz  libxslt  freetype2
Optional Deps   : pipewire: WebRTC desktop sharing under Wayland [installed]
                  kdialog: support for native dialogs in Plasma
                  gtk4: for --gtk-version=4 (GTK4 IME might work better on Wayland) [installed]
                  org.freedesktop.secrets: password storage backend on GNOME / Xfce
                  kwallet: support for storing passwords in KWallet on Plasma
                  upower: Battery Status API support [installed]
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 381.60 MiB
Packager        : Christian Heusel <gromit@archlinux.org>
Build Date      : Thu 18 Dec 2025 03:43:01 PM
Install Date    : Tue 23 Dec 2025 11:03:42 AM
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

chromium: 276 total files, 0 altered files

seth wrote:

Do you have an excessive amount or weird fonts installed?

Hmm, I guess that depends on your opinion of "excessive" and "weird". I do have a fair number of fonts installed:

# pacman -Qs "[t|o]tf" | grep "^local"
local/font-bh-ttf 1.0.3-7
local/gnu-free-fonts 20120503-8
local/noto-fonts 1:2025.12.01-2
local/noto-fonts-extra 1:2025.12.01-2
local/otf-font-awesome 7.1.0-1
local/otf-libertinus 7.051-1
local/sdl2_ttf 2.24.0-2
local/sdl3_ttf 3.2.2-3
local/texlive-fontsextra 2025.2-2 (texlive)
local/texlive-latexextra 2025.2-2 (texlive)
local/texlive-luatex 2025.2-2 (texlive)
local/ttf-anonymous-pro 1.003-8
local/ttf-bitstream-vera 1.10-16
local/ttf-caladea 20200113-4
local/ttf-cheapskate 2.0-18
local/ttf-croscore 20220810-3
local/ttf-dejavu 2.37+18+g9b5d1b2f-7
local/ttf-devicons 1.8.0-1
local/ttf-droid 20121017-11
local/ttf-fira-mono 2:3.206-4
local/ttf-fira-sans 1:4.301-2
local/ttf-google-fonts-git 1:r11850.3818680b3-1
local/ttf-hack 3.003-7
local/ttf-hack-nerd 3.4.0-1 (nerd-fonts)
local/ttf-inconsolata 1:3.000-5
local/ttf-lato 2.015-5
local/ttf-liberation 2.1.5-2
local/ttf-material-design-icons-desktop-git r2331.d72e308-1
local/ttf-merriweather 1:2.100-1
local/ttf-merriweather-sans 2.001-1
local/ttf-meslo 1.2.1-3
local/ttf-nerd-fonts-symbols 3.4.0-1 (nerd-fonts)
local/ttf-nerd-fonts-symbols-common 3.4.0-1
local/ttf-opensans 3.003-1
local/ttf-oswald 4.101-3
local/ttf-quintessential 1.001-5
local/ttf-roboto 3.014-1
local/ttf-roboto-mono 3.001-1
local/ttf-signika 1.002-3
local/ttf-symbola 13.00-7
local/ttf-ubuntu-font-family 1:0.83-2
local/woff2-font-awesome 7.1.0-1

seth · 2025-12-30 23:49:58

https://aur.archlinux.org/packages/ttf-google-fonts-git looks scary, but if it was the font list, you'd expect other electron clients (vivaldi is a chromium-based browser, it doesn't depend on an external electron binary but is the same tech) to be affected.
"~30s" is close to the 25s dbus timeout, but that doesn't explain the 95% CPU load.

I'd still look at those because "For the past couple of weeks" would expect you to have seen more reports (here or on the chromium bugtracker) if this was a common issue.

If it's not those, it's broadsword-time

killall chromium
strace -f -tt -o /tmp/chromium.strace chomium /path/to/some.pdf
du -h /tmp/chromium.strace # this could end up being huge, you might want to gzip it
cat /tmp/chromium.strace | curl -F 'file=@-' 0x0.st

loserMcloser · 2025-12-31 17:44:43

OK, thanks for your help. Does seem to be font related: if I uninstall ttf-google-fonts-git then the load time for a PDF is down to 2 or 3 seconds (but still not instant like other browsers/viewers). I've had ttf-google-fonts-git installed for years and never had an issue before. I'll think about submitting a bug report upstream.

seth · 2025-12-31 19:13:32

Did you change anything to your local fontconfig (different default font, substitution, language specific fonts, …)?

loserMcloser · 2025-12-31 19:27:28

I have some substitutions under

~/.config/fontconfig

to insert font awesome symbols into some other fonts, but haven't made an changes to that recently. I tried temporarily disabling that but issue remains. And a fresh user without that stuff has the same issue.

Last edited by loserMcloser (2025-12-31 19:27:48)

seth · 2025-12-31 23:37:28

My last guess w/o the strace and understanding that it *is* font related would be that chromium is maybe chasing symlinks in circles?
For some complete curveballs see https://aur.archlinux.org/packages?O=0&K=noglycin and https://wiki.archlinux.org/title/Chromi … nd_support (notably switching between gtk3 and gtk4)

roberto · 2026-01-02 13:46:20

I have the same issue and the same behaviour when removing the google fonts. With the same packages it was working with no issue before I've reinstalled Arch 1 month ago.

seth · 2026-01-02 16:02:40

The most obvious cause would be chromium - it moved from 142 to 143 on December 6th…

roberto · 2026-01-03 14:42:21

It seems an issue related to the number of fonts in the system due to a change released in Chromium on Nov 20th. The discussion is here https://www.reddit.com/r/chrome/comment … g_pdfs_in/ and request for a fix here https://issues.chromium.org/issues/462403025.

For the moment the only solution is to remove fonts from the linux installation. In my system I have 3200 fonts ( fc-list | wc -l ) and it takes about 5 secs to open a PDF.

loserMcloser · 2026-01-05 15:23:29

I also opened a chromium issue about it. I've just now added a comment with roberto's information.

@seth I've also attached an strace to that issue thread, if you're curious.

Last edited by loserMcloser (2026-01-05 15:24:38)

seth · 2026-01-07 20:48:42

There's an enormous amount of futexes and calls to what looks like the chromium singleton socket - it smells like *every/ font is loaded and also through an individual thread/process…
You maybe want to stress that this is a regression between 142 and 143 because something will have changed about the font loading code and that's what they need to look at and ask "does this change maybe not scale all that well"?
And then they also don't need a gazillion fonts, they can just cycle that code 1000 times and *see* how the change scales.

loserMcloser · 2026-01-23 17:16:08

Seems to be fixed in chromium 144.0.7559.59.

Arch Linux

#1 2025-12-30 15:48:31

[SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#2 2025-12-30 18:12:18

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#3 2025-12-30 22:21:38

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#4 2025-12-30 22:49:43

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#5 2025-12-30 23:21:59

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#6 2025-12-30 23:49:58

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#7 2025-12-31 17:44:43

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#8 2025-12-31 19:13:32

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#9 2025-12-31 19:27:28

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#10 2025-12-31 23:37:28

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#11 2026-01-02 13:46:20

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#12 2026-01-02 16:02:40

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#13 2026-01-03 14:42:21

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#14 2026-01-05 15:23:29

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#15 2026-01-07 20:48:42

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

#16 2026-01-23 17:16:08

Re: [SOLVED] Chromium: Displaying PDF takes ~30s and CPU ~95%

Board footer