I3status-rust: xrandr block important performance issue in Debian

[Ergus]

Hi:

I have been using the xrandr block in Arch linux for more than a year and it works normally. Recently I was trying it in Debian and the experience was terrible.

After some hours blaming the video driver, video configuration, xorg config etc etc etc I found that the source of the problem was the xrandr block!!!

I had the same config in arch and debian

[[block]]
block = "xrandr"
icons = true
interval = 2

And the screen keep freezing constantly, movement was interrupted constantly. Then I ran glxgears and it was stocking every a couple of seconds.

300 frames in 5.0 seconds = 59.998 FPS
218 frames in 5.0 seconds = 43.598 FPS
191 frames in 5.2 seconds = 36.382 FPS
211 frames in 5.0 seconds = 42.196 FPS
191 frames in 5.0 seconds = 38.189 FPS
235 frames in 5.0 seconds = 46.853 FPS
175 frames in 5.3 seconds = 32.822 FPS

after commenting that specific block everything ran faster, the stops disappeared and I got:

300 frames in 5.0 seconds = 59.992 FPS
300 frames in 5.0 seconds = 59.996 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 59.996 FPS
301 frames in 5.0 seconds = 60.000 FPS

In arch I haven't notices this, but after commenting the block there there was also a slight improve in performance too.

[ammgws]

Sounds like the same as this comment: https://github.com/greshake/i3status-rust/issues/274#issuecomment-560395604

What's the version of xrandr in your Debian install? All we do is call the command, so if there's any difference it would be in xrandr itself. Since it doesn't happen when using Arch, perhaps there's a bug that was fixed between the two versions.

[Ergus]

Arch:

xrandr program version       1.5.1
Server reports RandR version 1.6

Debian

xrandr program version       1.5.0
Server reports RandR version 1.5

[ammgws]

Hmm 4 years and a bunch of commits between those versions: https://gitlab.freedesktop.org/xorg/app/xrandr/-/commits/master

Wonder if there is anything there. Otherwise if you can, please compile 1.5.1 on Debian and see if you can reproduce.

[ammgws]

From a quick look the block first gets a list of monitors:
xrandr --listactivemonitors | grep \\/
Then runs this command for each monitor:
xrandr --verbose | grep -w '{} connected\\|Brightness' (replace {} with monitor name from first command)

Do running those command in a terminal in Debian produce the same issue?

[ammgws]

@Ergus Have you been able to investigate further?

[louislefevre]

From a quick look the block first gets a list of monitors:
xrandr --listactivemonitors | grep \\/
Then runs this command for each monitor:
xrandr --verbose | grep -w '{} connected\\|Brightness' (replace {} with monitor name from first command)

Do running those command in a terminal in Debian produce the same issue?

I use Arch not Debian, but if its any help I've been having this problem as well and running the second command causes lag every time. I've got around the problem for now by just setting the interval to something really high (e.g. 6000), since changing the brightness still works and the lag only occurs momentarily every 100 minutes.

[ammgws]

running the second command causes lag every time

@louislefevre Just to clarify, you can reproduce the issue just by running that command in a terminal?

If so then that means we can rule out i3status-rust itself as the cause and can start looking into why xrandr would do that in the first place, and possibly other ways we can get the information we need that doesn't cause lag.

[ammgws]

Closing due to inactivity and because there doesn't seem to be anything we can do on our side.