search

fflewddur / tophat

View CPU, memory, disk, and network activity in the GNOME top bar.
https://extensions.gnome.org/extension/5219/tophat/
GNU General Public License v3.0
323 stars 23 forks source link

TopHat causes composition stuttering when updating (Wayland) #105

Open asumagic opened 10 months ago

asumagic commented 10 months ago

I installed TopHat recently and noticed that I lose compositor frames whenever TopHat updates, even when at a 60Hz refresh rate. This does not reproduce when I disable the entire extension.
That stuttering however reproduces even if I disable every display option in the settings (i.e. no monitor is actually shown), so I cannot pinpoint it to anything in particular.

I'm using the latest TopHat version on GNOME 44.4 on Wayland, under Arch Linux. Some other miscellaneous details, as those involve things TopHat might be trying to monitor: my CPU is a 3900X (24 threads) and I have 6 ZFS datasets mounted.

I profiled the system using Sysprof while keeping glxgears on to make sure that there was something to composite, and filtered to a moment when stuttering occurs:

sysprof zoomed into when the stutter occurs

My guess is that the extension is doing too much work synchronously (though I don't know if it can do otherwise), which given GNOME's... curious composition and extension model causes the entire compositor to stutter.

fflewddur commented 10 months ago

Thanks for reporting this! Does the stuttering still occur if you disable animations in TopHat's preferences? I'm not too happy with the current state of the animation code anyway, and suspect that might be the issue here.

asumagic commented 10 months ago

It doesn't seem to be caused by animations, I still encounter the same stutters with these settings:

image

Also, __open/__read/__close being high up in the trace is probably because of poking at sysfs. Looking at the strace of the gnome-shell process seems to corroborate this as I can see TopHat walks through all of /proc (even when the CPU widget is disabled).

I'm curious if this reproduces on other machines. If so then maybe refreshing the process list only when opening the CPU view would save a bit of CPU and power at the cost of delaying the process view.