We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Exact steps to reproduce:
1. Provide some non-integer scrolling input to an SDL application (e.g. via double finger flick scroll on a touchpad on windows)
2. In the same instance of the appplication use a mouse with a discrete mousewheel that provides integer scrolling input
3. Scroll the mouse by 1 "tick" in alternating directions, repetitively

What happens is that SDL_MouseWheelEvent's generated by step 3 have a zero offset whenever the scrolling direction changes. In the extreme case of alternating 1-tick scrolls this causes the SDL application to not see any scrolling at all (rather, the application sees the events, but due to the offset being zero it is unable to infer the scrolling direction).

This directly follows from the logic in src/events/SDL_mouse.c . Step 1 makes sure that SDL_mouse.accumulated_wheel_x/y is non-integer. Suppose that non-integer is 0.123, then alternating ticks in step 3 will cause the value of accumulated_wheel_x/y to alternate between 0.123 and -0.877, never exceeding 1 in absolute value and thus integral_x/y is never nonzero.

Ideally a translation-invariant rounding should be used instead, so that rounding 'x' and 'x+1' produces different integers for all possible x. I propose to cut off at 0.5 and round towards negative infinity. Note that if precise scrolling causes the the accumulated value to go over 0.5 but under 1.0, this will cause the integral value to be 1 and the new accumulated value to be negative, but this is a better more predictable behavior than the one currently present.