Weird `MouseMotion` delta-y output

[woongzeyi]

Bevy version

0.13

What you did

I was trying to read mouse delta values from EventReader<MouseMotion> to implement camera movements.

What went wrong

Delta-y values were stuttery, resulting in rough vertical mouse movement.

Whilst delta-x values are normal, moving mouse horizontally is buttery smooth.

Additional information

Through some trial and error, I found out that this issue only appears when there is presence of any entity with Camera3dBundle component.

If entities with such component are removed, this issue will not show up.

This issue is not present in Bevy version 0.12.1.

I have also recorded a video demonstrating this issue.

Screencast.from.2024-02-29.16-55-22.webm

Here's the code used to test this issue: https://github.com/woongzeyi/bevy_testground/tree/mouse_movement

[rafalh]

I am also getting weird mouse input behavior on Linux although for me it happens in both axes. It may be platform specific...

Seems it could be be fixed with rust-windowing/winit@3d4c534 or another unrelated change.

cargo update should be enough, can anyone confirm please? I had the issue and it's now apparently gone after updating to winit 0.29.13

[rafalh]

Seems it could be be fixed with rust-windowing/winit@3d4c534 or another unrelated change.

Actually it broke the mouse events for me. I downgraded winit to 0.29.10 (0.29.11 didn't build) and mouse-look works properly in my game, like in Bevy 0.12. In winit versions 0.29.12 and 0.29.13, which include the mentioned "fix", it is broken...

[tim-blackbird]

Seems it could be be fixed with rust-windowing/winit@3d4c534

The code in that commit appears to be where this bug was introduced actually :p
The consume! macro specifically

I'll leave a comment for them

[aevyrie]

Filtering by f32::EPSILON seems wrong to me. Values closer to 0.0 have more precision than at 1.0, and f32::EPSILON is the ULP at 1.0.

0.0 minimum increment: 1.401298e-45
1.0 minimum increment: 1.192093e-07

So any mouse move smaller than 1.192093e-07 is now being filtered, which, for a gaming mouse with high sampling rate seems plausible, though that is a very small number, so this might be wrong.