Delayed mouse inputs after left click on macOS

[aevyrie]

Bevy version

This seems to be a long-running issue, at least as far back as 0.6.

[Optional] Relevant system information

macOS

What you did

Click and drag on the window and watch the event queue. The easiest way to replicate this visually is to just grab and move the window, dragging will hitch for a few frames, though the application itself will continue to update smoothly. This is because the events themselves are being delayed. You can also see this in the viewpoint to world example.

What went wrong

Mouse inputs stutter for a brief time before catching up. Seems to be related to rust-windowing/winit#1418 (comment).

Additional information

Instrumenting the mouse movement example demonstrates the issue:

INFO mouse_input_events: Frame 602
INFO mouse_input_events: MouseMotion { delta: Vec2(-36.0, -2.0) }
INFO mouse_input_events: MouseMotion { delta: Vec2(-35.0, -2.0) }
INFO mouse_input_events: Frame 603
INFO mouse_input_events: MouseMotion { delta: Vec2(-20.0, -2.0) }
INFO mouse_input_events: Frame 604
INFO mouse_input_events: Frame 605
INFO mouse_input_events: Frame 606
INFO mouse_input_events: MouseMotion { delta: Vec2(-31.0, -1.0) }
INFO mouse_input_events: MouseMotion { delta: Vec2(-29.0, -1.0) }
INFO mouse_input_events: Frame 607
INFO mouse_input_events: Frame 608
INFO mouse_input_events: Frame 609
INFO mouse_input_events: Frame 610
INFO mouse_input_events: Frame 611
INFO mouse_input_events: Frame 612
INFO mouse_input_events: Frame 613
INFO mouse_input_events: Frame 614
INFO mouse_input_events: Frame 615
INFO mouse_input_events: Frame 616
INFO mouse_input_events: Frame 617
INFO mouse_input_events: Frame 618
INFO mouse_input_events: Frame 619
INFO mouse_input_events: Frame 620
INFO mouse_input_events: Frame 621
INFO mouse_input_events: Frame 622
INFO mouse_input_events: Frame 623
INFO mouse_input_events: Frame 624
INFO mouse_input_events: MouseButtonInput { button: Left, state: Pressed, window: 0v0 }
INFO mouse_input_events: Frame 625
INFO mouse_input_events: Frame 626
INFO mouse_input_events: Frame 627
INFO mouse_input_events: Frame 628
INFO mouse_input_events: MouseMotion { delta: Vec2(-38.0, 0.0) }
INFO mouse_input_events: Frame 629
INFO mouse_input_events: MouseButtonInput { button: Left, state: Pressed, window: 0v0 }
INFO mouse_input_events: MouseMotion { delta: Vec2(-390.0, -2.0) }
INFO mouse_input_events: MouseMotion { delta: Vec2(-194.0, -2.0) }
INFO mouse_input_events: Frame 630
INFO mouse_input_events: Frame 631
INFO mouse_input_events: Frame 632
INFO mouse_input_events: MouseMotion { delta: Vec2(-75.0, -1.0) }
INFO mouse_input_events: MouseMotion { delta: Vec2(-78.0, -3.0) }
INFO mouse_input_events: Frame 633
INFO mouse_input_events: MouseMotion { delta: Vec2(-68.0, -1.0) }
INFO mouse_input_events: Frame 634
INFO mouse_input_events: MouseMotion { delta: Vec2(-75.0, -1.0) }

Somewhere around frame 607 is where the left mouse button is being pressed, however instead we see a huge gap in events until frame 624, where the press is registered, then another 4 frames until a small delta is received, then the release event is received, and finally, on frame 629 we see two huge mouse deltas show up, about 10x larger than normal. This is where the inputs "catch up" after the hitch.

[aevyrie]

I was able to find an absolutely disgusting fix: rust-windowing/winit#1418 (comment), however this ultimately needs to be fixed in winit.

[aevyrie]

Welp, it looks like this is a duplicate of:
#5778
#6075
#10658

I'm not sure how I didn't find these until now.

[Vrixyz]

I was able to find an absolutely disgusting fix: rust-windowing/winit#1418 (comment), however this ultimately needs to be fixed in winit.

Seems like there could be a fix from within bevy: following advices from #11052 (comment) ; prompted from rust-windowing/winit#1418 (comment).

[aevyrie]

Closing, as this is caused by a 3rd party app and is a duplicate.