Moving a window generates a backlog of move commands with high-speed mice

[rprichard]

I'm using a Logitech G400 mouse, which generates mouse input at 1000Hz. Apparently the more typical rate is around 100Hz. This mouse generates noticeably more X11 events (e.g. run xev | nl).

Using Blackbox, when I move a window, there is a substantial lag from moving the mouse pointer and the window itself moving. Presumably there is a message/event queue somewhere with move commands in it, and some(?) applications aren't able to keep up with the move commands.

With a slower-speed mouse, this problem doesn't happen.

Counter-intuitively, window resizing isn't affected.

It doesn't matter whether I use Alt-mouse or click the title/resize-box.

This problem does affect other window managers (e.g. xfwm4, but I also saw the problem with MATE and GNOME Flashback). Sometimes enabling compositing seems to fix the issue. I hacked around the problem in xfwm4 by adding rate limiting. I also wrote my own alternative to altdrag on Windows, where I instead fixed the problem using synchronous move/resize operations on a dedicated thread, driven by a command buffer where I collapsed subsequent move/resize commands.

I might just give up and find a slower mouse.

Blackbox version: 0.72, commit 8c9e2af7d34ea076f684ce47d8e4f0268b054c71.

YouTube video of the issue: https://www.youtube.com/watch?v=mwBH_AkhW_Q&feature=youtu.be

[rprichard]

I wonder if a faster computer would also mitigate this problem? I'm using a desktop from ~2009 with a 4-core Core i7 860 2.8GHz CPU.

[bbidulock]

BB doesn't support _NET_WM_SYNC_REQUEST{,_COUNTER}. When moving or resizing a heavy window (like Firefox or Chromium), this mechanism does not issue another resize/move request until the client acknowledges that it has completed the previous one. Intermediate move/resize requests generated by input devices awaiting completion are discarded and only the most recent request is issued once the client signals that it has completed the previous one. When the application is multi-threaded, it can do this itself when the window manager does not support this feature. The difference is, when the window manager does not support, the window and border resizes before its contents leading to staggering border artifacts until the application catches up. This mostly affects resize and not move.

Not many light-weight window managers support _NET_WM_SYNC_REQUEST. Openbox and Metacity have had support since forever. I added support to ADWM and some other window managers, but not blackbox.

Give your mouse a try on Openbox or Metacity and see if the problem exists there too.

[bbidulock]

xfwm4 sending unnecessary synthetic ConfigureNotify events when moving surely does not help.

[rprichard]

The problem also happens with Openbox (3.6.1-1ubuntu2) and Metacity (1:3.18.7-0ubuntu0.3). On Xubuntu 16.04, I tried moving/resizing an XFCE terminal and a Chrome window. Resizing is always fast. With Openbox, I can move a terminal quickly, but Chrome lags. With Metacity, moving either window lags.

[rprichard]

I might just give up and find a slower mouse.

Instead, I studied the Windows driver software with Wireshark and wrote a tool to set the polling rate and DPI: https://github.com/rprichard/logitech-g400-config.

The Logitech G400 mouse supports 125 Hz, 250 Hz, 500 Hz, and 1000 Hz settings. At 500 Hz and above, Openbox, Blackbox, and Metacity all lag. They all work at 250 Hz.