macOS mouse events are laggy

[overdrivenpotato]

• macOS 11.5.2
• winit 0.26.1

Scroll and mouse move events on macOS feel like they run at a substantially lower frame rate than the window. This is exhibited in this wgpu tutorial. Near the bottom of the page, there is a "Try Tutorial12_camera" button, which opens up the demo. Scrolling on the demo in-browser is smooth, but when compiling and running it as a native application on macOS, scrolling (and dragging) is laggy.

I'm running into this issue in a different project (also using wgpu), so it's not specific to that particular demo. Using keyboard keys in both the web and native versions results in smooth frame rates, so it's not the demo itself that is running slower.

[madsmtm]

Tried the tutorial you mentioned, using macOS 10.14.6 Mojave.

I don't think I can reproduce what you're seeing with scrolling, that part seems just as smooth to me.

I think I see what you mean with the mouse movement (specifically DeviceEvent::MouseMotion), e.g. when moving the cursor very slowly, you can get it to move what appears to be around 2-3 pixels before the display updates. Is this what you mean? Though I think that issue is present in Firefox as well.

Internally we're using NSEvent -deltaX and NSEvent -deltaY, but, while these return floating point values, it appears that the values are actually only ever integers, meaning that sub-pixel mouse movement is lost (see also this StackOverflow question).

I don't really think there's a way to solve this? Apart from not using DeviceEvent::MouseMotion and instead using WindowEvent::CursorMoved and tracking deltas manually.

[overdrivenpotato]

That's odd that you can't reproduce the issue. The latency of 2-3 pixels before the display updating isn't what I mean (although accumulating frame lag may be a different issue...). I did some more digging and found a better way to check whether the lagging event issue is occurring.

The following diff against the linked repo illustrates the issue. I've also been able to reproduce it on another machine, this time running Monterey - a 2016 13" MacBook Pro. So it's not just a Big Sur bug, and it's not specific to my machine.

diff --git a/code/intermediate/tutorial12-camera/src/lib.rs b/code/intermediate/tutorial12-camera/src/lib.rs
index 16d972b4..ef2f6bb4 100644
--- a/code/intermediate/tutorial12-camera/src/lib.rs
+++ b/code/intermediate/tutorial12-camera/src/lib.rs
@@ -546,6 +546,7 @@ impl State {
                 ..
             } => self.camera_controller.process_keyboard(*key, *state),
             WindowEvent::MouseWheel { delta, .. } => {
+                println!("MouseWheel");
                 self.camera_controller.process_scroll(delta);
                 true
             }
@@ -724,6 +725,7 @@ pub async fn run() {
             }
             // UPDATED!
             Event::RedrawRequested(window_id) if window_id == window.id() => {
+                println!("RedrawRequested");
                 let now = instant::Instant::now();
                 let dt = now - last_render_time;
                 last_render_time = now;

Running the example (cd code/intermediate/tutorial12-camera; cargo run --release) and scrolling results in a strange order, with scrolling being updated only every other frame:

MouseWheel
MouseWheel
RedrawRequested
RedrawRequested
MouseWheel
MouseWheel
RedrawRequested
RedrawRequested
MouseWheel
MouseWheel
RedrawRequested
RedrawRequested
MouseWheel
MouseWheel
RedrawRequested
RedrawRequested

Adding a println! to the MouseMotion event results in the same thing:

MouseMotion
MouseMotion
RedrawRequested
RedrawRequested
MouseMotion
MouseMotion
RedrawRequested
RedrawRequested
MouseMotion
MouseMotion
etc ...

This explains why mouse events feel so choppy. Any ideas?

[frewsxcv]

This is potentially a duplicate of #1418