Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xrandr block important performance issue in Debian #668

Closed
Ergus opened this issue May 11, 2020 · 8 comments
Closed

xrandr block important performance issue in Debian #668

Ergus opened this issue May 11, 2020 · 8 comments

Comments

@Ergus
Copy link

Ergus commented May 11, 2020

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
Copy link
Collaborator

ammgws commented May 11, 2020

Sounds like the same as this comment: #274 (comment)

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
Copy link
Author

Ergus commented May 11, 2020

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
Copy link
Collaborator

ammgws commented May 11, 2020

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
Copy link
Collaborator

ammgws commented May 11, 2020

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
Copy link
Collaborator

ammgws commented Jun 2, 2020

@Ergus Have you been able to investigate further?

@louislefevre
Copy link

louislefevre commented Jun 15, 2020

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
Copy link
Collaborator

ammgws commented Nov 6, 2020

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
Copy link
Collaborator

ammgws commented Dec 15, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants