GNOME Bugzilla – Bug 778926
[gnome-terminal] Very poor scrolling performance on wayland with high DPI
Last modified: 2018-05-02 18:08:54 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.
Could you guys please check whether, by any chance, this recent VTE commit: https://git.gnome.org/browse/vte/commit/?id=809e79770 [bug 771899] causes any noticeable performance improvement?
Just tested that commit (0.50.2-4ubuntu2 + that patch) on Ubuntu artful, and it seems to make ALOT of difference already. Its way faster now. But not yet the speed we had on X.
Yes, there is now little difference in performance between with and without scrollbar.
Great to hear this! (In reply to jean-louis from comment #16) > [...] But not yet the speed we had on X. Could you please elaborate on this? How "usable" is this now, does it still lag the whole desktop (as you reported at https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1746949)? Or just simply a "bit" slower than on X?
I don't see any major improvement with this commit but it seems to me now that vte3 performance is comparable on X11 & Wayland, but unrelated to this commit.
Performance suffers a lot with scale 2 drawing (and large window sizes), so maybe what performance you remember from X was from before we had Hi-DPI.
GNOME Shell lagging is much more noticeable on Wayland as it's also responsible for input handling and updating the mouse cursor. On X this happens independently from the compositor.
When I reported the bug, I was comparing performance on the same machine with HiDPI in both cases. Looking back on it, I do not think it's a very scientific comparison as "CPU usage" is a vary vague indication of actual performance on a laptop with CPU frequency scaling. It may be that it was using more % on wayland, but actually fewer or same amount of CPU cycles.
(In reply to François Guerraz from comment #22) > Looking back on it, I do not think it's a very scientific comparison [...] Anything along the lines of 30%+ CPU usage for scrolling every tenth of a second is obviously pretty bad, no need for more accurate CPU measurement here.
(In reply to Egmont Koblinger from comment #18) > Great to hear this! > > (In reply to jean-louis from comment #16) > > [...] But not yet the speed we had on X. > > Could you please elaborate on this? How "usable" is this now, does it still > lag the whole desktop (as you reported at > https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1746949)? Or > just simply a "bit" slower than on X? Well if there is some terminal open with fast scrolling text (tail -f for example). It still gives some fps drop on the desktop. But its like 10% anymore of what it was before the patch applied.. So way faster, not as fast as it was on X. But surely workable now!
Now that 3.28 is out, I've looked into it properly again, that is monitoring not only the CPU usage but also the cpu frequency and power usage. On my system (Skylake, HiDPI screen, Gnome 3.28), on battery, running $ while true; do sleep 0.1; echo 1; done On X, average cpu frequency is about 550MHz, terminal + X + gnome-shell cpu usage combined is 25%, average power usage is 7.49W On Wayland , average cpu frequency is about 650MHz, terminal + gnome-shell cpu usage combined is 50%, average power usage is 10.17W So we still have a measurably huge regression in cpu & power usage.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/763.