Horizontal Scrolling Backwards on Windows

[aevyrie]

Issue
Horizonal and vertical scrolling directions do not match.

Expected Behavior
Both x/y should behave the same, e.g. both directions are "natural" scrolling on the touchpad.

Observed Behavior
Vertical scrolling respects OS and is in the "natural" direction. Horizontal scrolling is inverted and does not follow the "natural" scroll direction. First noticed when using native builds of emilk/egui#356.

Reproducing the Bug
I've created a minimal reproducible winit example here: https://github.com/aevyrie/winit_scroll_test.

[msiglreith]

For my understanding as there is #2105 as well: The x direction should be inverted on all platforms? What's the desired coordinate system for scrolling?

[aevyrie]

For my understanding as there is #2105 as well: The x direction should be inverted on all platforms? What's the desired coordinate system for scrolling?

No, see here: #2101 (comment). I think the goal is to match GLFW prior art.

At least in the case of egui using winit, it appears that not all linux distros behave the same either, so I don't think it's true that it is inverted on all platforms.

[akhilman]

I have the same behaviour on Manjaro Gnome with trackball mouse and Debian Xfce with touchpad. In both machines the X-axis is flipped. Tested with https://github.com/aevyrie/winit_scroll_test.

[msiglreith]

Unfortunately, I didn't get horizontal scrolling to work on any my devices so far with winit ):
Regarding the coordinate system: currently it's defined in winit as https://docs.rs/winit/latest/winit/event/enum.MouseScrollDelta.html#variant.LineDelta, so basically bottom-left corner.

Do the raw value output match with coordinate system in the documentation? The window position coordinate system is top-left IIRC which might be confusing. Overall I don't mind if we adapt the GLFW approach but I want to be sure that it matches with the documentation and it's clear if this a bugfix or breaking change.

[aevyrie]

Closed by #2105