GNOME Bugzilla – Bug 778926
[gnome-terminal] Very poor scrolling performance on wayland with high DPI
Last modified: 2017-12-21 09:00:10 UTC
On wayland, just running while true; do echo 1; sleep 0.1; done is enough to have gnome-terminal & gnome-shell using 30%CPU *each*. This is not immediate and pre-filling the buffer helps reproducing the issue.
For comparison on X11, the combined CPU usage of gnome-shell, gnome-terminal and Xorg is negligible (<10% whilst keeping the CPU at the lowest frequency)
Is that with a gnome-terminal from upstream git/tarball, or from some distro with the transparency patch (e.g. fedora) ?
That's on arch, the PKGBUILD shows that there is no patch applied at all. Just in case it's relevant, I have a HiDPI screen with UI scaling set to 2.
Since gnome-terminal & vte don't have any gdk backend specific code, it's highly unlikely to be due to something g-t/vte do. Most likely some problem in gtk+/gdk, and possibly a duplicate of bug 772075.
I'm sure you know but the patch for bug 772075 is included in the version I'm using. Also, even if the vte being refreshed is in a tab in the background, CPU usage is still as high even if there is nothing visible to refresh.
(In reply to François Guerraz from comment #5) > I'm sure you know but the patch for bug 772075 is included in the version > I'm using. How could I know one way or the other, since the gtk+ version used is not mentioned in this bug report.
Apologies, this comment came out wrong :-) I'm using extra/gtk3 3.22.8-1 from arch, which AFAIK includes that patch.
Created attachment 346436 [details] gnom-shell profiling With gtk3 2.22.8 arch compiled with -fno-omit-frame-pointer
Created attachment 346437 [details] gnome-terminal-server profiling With gtk3 2.22.8 arch compiled with -fno-omit-frame-pointer
I found a workaround: unticking "Show scrollbar" in the g-t profile reduces the CPU usage to almost nothing (similar to the normal behaviour on X11)
I see this message from gnome-terminal-server in my log a few times: Allocating size to GtkScrollbar 0x1670390 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? Maybe it's related.
I think what's happening is that with the scrollbar visible, each scroll adjustment change queues a full resize of the window, which in turn recalcs the window shadows which for some reason are (/were?) expensive to redraw on high DPI.
Not sure about that, disabling the scrollbars only helps, it doesn't fix the issue and the problem also occurs in full screen mode and there are no shadows in that case (or at lease, they should not be calculated).
FYI this is still unresolved and it's a shame that a scrolling terminal uses more power that watching an HD movie. Can you confirm you can at least reproduce the problem? If not I can try to provide more information, find a more detailed test case, anything.