Incredibly slow and laggy resizing with bspwm and sxhkd

btw · 2020-05-24 17:09:54

Hey all, I'm decently new to arch but not at all new to linux, and I've come across an issue that I can't seem to fix on my own. When using bspwm as my window manager, and sxhkd for hotkeys, I have ridiculously slow resizing of tiled windows, but interestingly, floating windows are fine. This happens regardless of whether or not a compositor is used, the only difference is when I use a compositor, it stutters and lags, whereas without a compositor it just lags behind with increasing latency as window resizing continues. I have noticed that when resizing, xorg jumps to 100% or more CPU usage (changing xorg conf did not help), and when searching for a solution for this, found only suggestions to change the frequency of sxhkd, which is a long deprecated option, and to change the shell used to run sxhkd to sh, to help drawing commands get executed faster, but this didn't help either. I am guessing that this issue is caused by sxhkd attempting to draw windows every time the mouse sends movement, which is 1000 times per second, and pins my CPU. If any of you could help, I would greatly appreciate it.

seth · 2020-05-24 22:15:16

I don't think https://bbs.archlinux.org/viewtopic.php?id=255730 is dead yet. You could add your findings there and report this thread for deletion.

Also: did you actually determine sxhkd to be the cause (does the problem go away if you kill it)?
From a glimpse at its source code, it doesn't even seem to cerate a drawable and resizing (by mouse) seems to be handled by bspwm? Do you use any modifiers (alt, win, ..) here?

btw · 2020-05-26 02:02:50

Sorry! Didn't realize the thread was alive, and sxhkd was not the cause, I just assumed it was because of older fixed issues relating to frequency in sxhkd, and it generally being used for bindings. The problem persisted after killing it, and I am using the default pointer key (Super) to draw windows.

seth · 2020-05-26 05:50:01

It's 12 days old and you hooked into it after 6.

The resize is slow because one or more clients a very expensive to resize, ie. when you resize *that* window, it will resize very slow. On a tiled layout, typically many windows resize at the same time - this is why individual floating windows are fine.
What brings us to the used driver and the involved windows:
InvisibleRasta uses the nvidia blob and it's notoriously slow at resizing GL windows (because that's not what GL was designed for) and so seem you, so the next question is what your window stack looks like and whether you're using eg. terminal emulators like kitty that rely on OpenGL acceleration.

btw · 2020-05-26 15:29:17

Even with transparency and blur on urxvt, in floating windows resizing performs exactly as it should, but as soon as I put a firefox window tiled next to it, or another terminal, the performance goes to crap. Same happens with two firefox windows, etc, but xorg always jumps to 100% cpu usage, no matter the window type, the only difference is how long it stays at 100%, as it varies from 0.3-3 seconds delay. If it's the nvidia drivers being bad at resizing gl windows, and I don't have any windows using opengl acceleration (that I know of, I've really only been using firefox and urxvt), where do I go from here, other than to remove nvidia drivers and move to nouveau?

seth · 2020-05-26 15:37:32

Firefox uses opengl acceleration (and is in general slow to resize because re-rendering webpages is expensive)
If it's the GL context, nouveau will resize faster (but probably be inferior in every other regard) - otherwise not.

Ideally, bspwm would allow for some rubberband or lazy resize feature to lower the load from resizing windows, but idk whether that's the case (never used it) …

… apparently not:
https://github.com/baskerville/bspwm/issues/1054
https://github.com/baskerville/bspwm/issues/839

eskoONE · 2021-05-20 17:54:30

this issue can be resolved by adding

bspc config pointer_motion_interval 40

to you bspwmrc. while 40 works for me, you might need to increase it to 50 or more to have it work more smoothly for you.

source

putting this in here in case others try to solve the same issue, as this was the first entry on ddg for me without a solution.

Last edited by eskoONE (2021-05-20 17:56:05)

Arch Linux

#1 2020-05-24 17:09:54

Incredibly slow and laggy resizing with bspwm and sxhkd

#2 2020-05-24 22:15:16

Re: Incredibly slow and laggy resizing with bspwm and sxhkd

#3 2020-05-26 02:02:50

Re: Incredibly slow and laggy resizing with bspwm and sxhkd

#4 2020-05-26 05:50:01

Re: Incredibly slow and laggy resizing with bspwm and sxhkd

#5 2020-05-26 15:29:17

Re: Incredibly slow and laggy resizing with bspwm and sxhkd

#6 2020-05-26 15:37:32

Re: Incredibly slow and laggy resizing with bspwm and sxhkd

#7 2021-05-20 17:54:30

Re: Incredibly slow and laggy resizing with bspwm and sxhkd

Board footer