Trenchbroom: Poor mouse look performance under Linux with KDE

[eGax]

System Information

Manjaro Linux KDE 64bit
GTX760
32GB RAM
TrenchBroom V2.1.0-RC4

Expected Behavior

To hold down the right mouse button to look around without screen studdering. The tighter the turns made the chopper it seems. Appears at worst a few seconds in between screen updates where the screen jumps up to a 1/2 inch intervals at worst to a 1/16 of an inch(sometimes a little better) at best. This didn't seem like much of an issue until sometime after the windows fixes. Last night while trying to map over the course of a few hours is when it really was apparent to me how bad it was.

Steps to Reproduce

In my Linux OS under the KDE desktop environment start a new map or existing, hold down the right mouse button and move the mouse around, adding in the use of WASD movement keys makes it worse. WASD movement by themselves seems fine for the most part.

Same OS, but under the openbox DE the issue is gone from what I can see.

Thank you very much!

[ericwa]

Can reproduce on Ubuntu 18.10 with Nvidia driver, and KDE installed (package kubuntu-desktop), TB 2.1.0.

WASD movement seems pretty smooth. Holding RMB for mouselook is very choppy, if I hold RMB and move the mouse in a circle quickly the TB window stops updating entirely, seems like it's getting flooded with mouse events or something.

In the default Ubuntu desktop, WASD is also smooth and RMB choppy. It seems a bit worse in KDE but it's hard to tell.

[kduske]

WASD is butter smooth on Ubuntu 18.04 on my laptop with default Ubuntu Gnome desktop (no VM). I don't think that testing this in a VM is useful since VMs tend to screw with mouse event handling (some VMs like Parallels have settings to change the way mouse events are generated in the guest OS).

We have already tried many different approaches to get this to run smooth on all platforms, and the current implementation is fine for most platforms. I'm not sure what to do about this, quite frankly. We cannot fix this for all platforms since wx doesn't seem to shield us properly from differences in event handling on the platforms.

[ericwa]

I'll have a look. My testing was also on a real PC, not a VM.

[kduske]

Alright!

[ericwa]

Upon testing a bit more, the severe choppiness and freezing in KDE only happens with my 1000Hz mouse. The other mouse I have is 125Hz and is reasonably smooth in KDE (seems worse than Windows on the same computer, though), it can't freeze the viewport either.

I used this to double check the mouse report rate:
https://zowie.benq.com/en/support/mouse-rate-checker.html

I suspect this is why we're getting different behaviour on KDE, rather than a difference between 18.04 and 18.10

[eGax]

That now makes more sense since sometimes I also do use a gaming mouse that can go up to 8200 DPI, 12000 FPS and with a 1000 Hz polling rate. The rest of the time I use a 125Hz Kensington Expert Mouse Trackball. I can say it is definitely worse using the gaming mouse under KDE just as you found.

[kduske]

So I suppose we get too many mouse events. Each mouse event triggers a redraw, and I think it will block the idle events since those are only sent if the event queue is empty. One thing to try is to poll the fly helper when mouse events arrive.

[ericwa]

So I suppose we get too many mouse events. Each mouse event triggers a redraw,

Not an immediate redraw, though. via MapView3D::cameraDidChange they call Refresh() which schedules one at the end of the event loop.

and I think it will block the idle events since those are only sent if the event queue is empty. One thing to try is to poll the fly helper when mouse events arrive.

That makes sense, yeah. But the first bug I'm looking at doesn't involve idle events or the fly mode helper at all; if you just hold RMB and move the mouse quickly with a 1000Hz mouse, the viewport freezes completely until you stop moving the mouse.

I stuck some logging in MapView3D::cameraDidChange and RenderView::OnPaint, and when I move the mouse quickly with RMB held down, there is a constant stream of MapView3D::cameraDidChange but RenderView::OnPaint never runs at all as long as I keep moving the mouse. This indicates that the mouse events are arriving at the front of the event queue, which is a problem. (I also confirmed this by queueing a custom event type inside MapView3D::cameraDidChange, which is bound to a handler that just prints a line to stdout, and it's possible to postpone this from running indefinitely by moving the mouse).

It looks like the problem is wxwidgets is calling gdk_window_get_pointer at the top of their motion_notify callback
https://github.com/wxWidgets/wxWidgets/blob/v3.1.1/src/gtk/window.cpp#L1810

Hard to find clear documentation* but it sounds like calling gdk_window_get_pointer queues up more motion events, so by doing that at the top of the motion_notify callback, the motion events get queued before anything else, which matches what I was seeing. I just moved the block of code that calls gdk_window_get_pointer to the end of the gtk_window_motion_notify_callback and it seems to fix the issue with no changes in TB.

** docs I was looking at:

• https://developer.gnome.org/gdk3/stable/gdk3-Events.html#gdk-event-request-motions
• https://www.linuxtopia.org/online_books/gui_toolkit_guides/gtk+_gnome_application_development/sec-gdkevent_5.html

[kduske]

Nice! I suppose we could submit a ticket on wx's bug tracker and attach the patch, they usually are very quick to address any issues. Until then, we can use our own patching to fix this particular issue.