Compress pointer tracking events. about bspwm

[ThomasAdam]

On 5 February 2013 23:24, Steven [email protected] wrote:

Currently, every pointer tracking event is handled causing a significant
amount of lag when resizing. This is a fairly common problem and most GUI
toolkits handle it by dropping intermediate mouse positions.

No; they flush pending XConfigureNotify requests. Your slowness is
likely down to the fact an external program is used to track mouse
movements, which for a WM is utterly insane.

-- Thomas Adam

[Stebalien]

While that contributes to the problem, if it were the sole problem, all windows would lag the same amount when resized. However, resizing two firefox is relitavely smooth while resizing two xterm windows is extremely laggy.

Also, I gave the example about how GUI toolkits track mouse movements (they do drop intermediate events) because I know next to nothing about how window managers work.

[Stebalien]

One possible way to reduce the lag of having a second program handle mouse movements would be to allow bspc to accept a stream of input and have sxhkd pipe (x,y) pairs to bspc. That is, calling bspc grab_pointer * would cause bspc to write 'grab_pointer ' to bspwm's socket and then, instead of closing the bspc socket, bspwm would continue to read mouse positions from this socket. Of course, I haven't tried implementing this so I don't even know if it will work...

[baskerville]

In fact the slowness has nothing to do with any of the above!

I just tried this:

diff --git a/window.c b/window.c
index 312dbc4..42027ae 100644
--- a/window.c
+++ b/window.c
@@ -186,6 +186,8 @@ void adopt_orphans(void)

 void window_draw_border(node_t *n, bool focused_window, bool focused_monitor)
 {
+    return;
+
     if (n == NULL)
         return;

With this patch applied, the resize_tiled action becomes very smooth 😲.

[baskerville]

The single-border branch removes the outer and inner borders ✨:
3b77dd4
It will be merged into master.