Changes to an unmapped GtkScrollbar's adjustment cause Xorg load
Steps to reproduce
Either use this tiny reproducer: gtk-scrollbar.c, gtk-scrollbar.ui;
or, as found at Red Hat bug 1513935, open a gnome-terminal
with two tabs, in one of them produce continuous large traffic (e.g. seq 1000000000
), and switch to the other one.
Watch the load of the Xorg server process, e.g. top -p $(pidof Xorg)
.
Current behavior
You see a significant increase in Xorg's CPU usage.
On my system, without the aforementioned test running, its CPU usage is around 0.3% and TIME+ increases by about 0.01s on every screen update of top (3 seconds).
With the rest running, Xorg's CPU usage is around 10%, TIME+ increasing by about 0.30s on every update.
Expected outcome
When the scrollbar is unmapped, changes to its adjustment should generate no work for Xorg whatsoever.
Preferably, when the scrollbar is mapped, but the changes to the adjustment don't result in user-visible changes, it shouldn't generate any Xorg work either.
Version information
GTK 3.24.12 on Ubuntu 19.10. (Original report on Fedora 28.)
Additional information
If the scrollbar is hidden (as in "gtk_widget_hide"), the load increase doesn't occur. In the test code you can do it by uncommenting the commented lines. In gnome-terminal you can test by Preferences -> the profile -> Scrolling -> don't Show scrollbar.
If the parameters of the adjustment don't change (uncomment pos++
in the example) then the load increase doesn't occur either. (Note: VTE increases the lower and upper bounds and the value on every new line that scrolls in, just like the tiny reproducer code.)
I couldn't reproduce on Wayland, but maybe I was just looking at the wrong process's load.
Let me emphasize, just in case, that I'm not talking about the load of the reproducer GTK app.