3 ms·

> 100+ tabs open across multiple desktops. My wimply little MacBook Pro doesn't seem to mind. There's a bug on Linux where background windows continue renderin

> 100+ tabs open across multiple desktops. My wimply little MacBook Pro doesn't seem to mind. There's a bug on Linux where background windows continue rendering, even if they're in an inactive workspace or not visible in any other way. This really hits performance, but it doesn't seem to be fixable due to some limitation on GTK3. If I hide/resize my system status-bar, every single window gets resized to match the new available screen space. Firefox re-renders all content in all windows, causing multiple CPUs to spike to 100%. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1880467 https://bugzilla.mozilla.org/show_bug.cgi?id=1880467 In fact, there are a lot of bugs which are basically "unfixable due to limitations in GTK3". So the experience is likely quite different that on other platforms. Regrettably, there don't seem to by any plans to move away from GTK in future.

Arnavion 1y ago
Just an idea. In my SwayWM setup, a) I run every application in its own cgroup (via systemd-run), and b) I have a daemon that subscribes to window and workspace events, gets the current tree, figures out the PIDs corresponding to invisible vs visible windows, figures out the cgroups corresponding to those PIDs, and then uses cgroup freezer file to freeze / unfreeze them. Other than a few hard-coded exceptions that I want to run while invisible (IRC client etc), any invisible application is transparently frozen and unfrozen. For "single-instance applications" like firefox, launching a new firefox while the existing one is frozen will hang, so instead of launching /usr/bin/firefox directory I have an intermediate ~/.local/bin/firefox script that unfreezes the firefox cgroup and then exec's /usr/bin/firefox. Of course if at least one FF window is visible then this doesn't help with your problem, since the cgroup as a whole will be unfrozen. It only helps if none of the FF windows are visible.
yellowapple 1y ago
I can't seem to reproduce any CPU spikes on my end when repeatedly hiding/unhiding various GNOME toolbars (top or bottom).

Arnavion 1y ago

Just an idea. In my SwayWM setup, a) I run every application in its own cgroup (via systemd-run), and b) I have a daemon that subscribes to window and workspace events, gets the current tree, figures out the PIDs corresponding to invisible vs visible windows, figures out the cgroups corresponding to those PIDs, and then uses cgroup freezer file to freeze / unfreeze them. Other than a few hard-coded exceptions that I want to run while invisible (IRC client etc), any invisible application is transparently frozen and unfrozen. For "single-instance applications" like firefox, launching a new firefox while the existing one is frozen will hang, so instead of launching /usr/bin/firefox directory I have an intermediate ~/.local/bin/firefox script that unfreezes the firefox cgroup and then exec's /usr/bin/firefox. Of course if at least one FF window is visible then this doesn't help with your problem, since the cgroup as a whole will be unfrozen. It only helps if none of the FF windows are visible.

yellowapple 1y ago

I can't seem to reproduce any CPU spikes on my end when repeatedly hiding/unhiding various GNOME toolbars (top or bottom).