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.

Bug 3432 - [patch] macOS 10.12: small scrolls (1 wheel notch) don't generate events
Summary: [patch] macOS 10.12: small scrolls (1 wheel notch) don't generate events
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: HG 2.1
Hardware: x86 Other
: P2 normal
Assignee: Eric Wasylishen
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-21 17:47 UTC by Eric Wasylishen
Modified: 2018-03-12 04:40 UTC (History)
3 users (show)

See Also:

Attachments
proposed fix (590 bytes, patch)
2016-09-21 17:47 UTC, Eric Wasylishen 		Details | Diff
Proposed patch (570 bytes, patch)
2018-03-09 03:06 UTC, Eric Wasylishen 		Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Wasylishen 2016-09-21 17:47:09 UTC 
Created attachment 2566 [details]
proposed fix

If I run the "testrelative" SDL demo with "--info all", rolling the scroll wheel one "notch" doesn't generate a scroll event. If I keep rolling it, I will start to see scroll events logged. This is with a logitech G400, or a microsoft ergonomic mouse.


What's happening is, in Cocoa_HandleMouseWheel the deltaY for
scrolling the scroll wheel one notch is 0.00172424316. SDL adds 0.9 to
that, and the resuting value is truncated to an int which results in
0.

I don't think this happened in OS X 10.11.

Attaching a patch that uses floor/ceil instead of adding/subtracting 0.9. I'm not sure if the use of 0.9 was to deliberately filter out scrolls with a abs(delta)<0.1, or if it was just an accident.
Comment 1 Martijn Courteaux 2016-09-21 23:45:02 UTC 
This problem should be resolved once someone finally decides to take a look in my precise scroll events patch (https://bugzilla.libsdl.org/show_bug.cgi?id=2293). You could use that patch instead for accurate floating-point scrolling amounts.
Comment 2 Alex Szpakowski 2016-09-24 16:31:13 UTC 
Thanks Eric, this should be fixed as of https://hg.libsdl.org/SDL/rev/7f3be5258f80


(In reply to Martijn Courteaux from comment #1)
> This problem should be resolved once someone finally decides to take a look
> in my precise scroll events patch
> (https://bugzilla.libsdl.org/show_bug.cgi?id=2293). You could use that patch
> instead for accurate floating-point scrolling amounts.

That's a separate issue - this particular bug is about a regression in SDL due to a change in macOS. Also I'm not sure your patch handles precise scrolling properly in macOS since it doesn't make use of -[NSEvent scrollingDeltaX/Y] on 10.7+.
Comment 3 Martijn Courteaux 2016-09-24 17:13:03 UTC 
@Alex: I'm not sure what the difference is between `deltaX` and `scrollingDeltaX`. I can try scrollingDeltaX/Y tomorrow. However, I'm using my patch on macOS Sierra for over a month now, and works fine. However; I had to add a factor 5 to make things scroll at the normal speed on both macOS Sierra and OS X. I'll have a look at the "preferred way" with scrollingDeltaX, and hopefully this will fix the factor 5-ish slowness.
Comment 4 Eric Wasylishen 2018-03-09 03:01:52 UTC 
This bug was reintroduced by https://hg.libsdl.org/SDL/rev/68a80d7afec3

The steps to reproduce are the same: run the "testrelative" SDL demo with "--info all", 
connect a USB mouse with a scroll wheel, and roll the scroll wheel one "notch". You'll get log output like:

testdraw2[1644:67222] INFO: SDL EVENT: Mouse: wheel scrolled 0 in x and 0 in y (reversed: 1) in window 1



As far as I can tell macOS doesn't have an API for getting the number of "wheel notches"; I get a deltaY of 0.100006 for one "notch", and it's heavily accelerated (if you roll the wheel quickly you'll get large deltas). So NSEvent's deltaY is only meant to be used for scrolling a scroll view, with the given distance in points, not something like selecting an item in a game.

Maybe looking at the IOHIDManager API is the correct solution here?
Comment 5 Eric Wasylishen 2018-03-09 03:06:03 UTC 
Created attachment 3190 [details]
Proposed patch

Here's a temporary patch that at restores the foor/ceil in Cocoa_HandleMouseWheel.
Not ideal, but at least it restores the ability to scroll one notch of a mousewheel.
Comment 6 Sam Lantinga 2018-03-11 05:15:18 UTC 
Patch applied!
https://hg.libsdl.org/SDL/rev/32b708d2f684

This seems like a reasonable workaround, giving people the behavior they would expect from the API. Feel free to close this if you think this is sufficient for the long term.
Comment 7 Eric Wasylishen 2018-03-12 04:40:45 UTC 
Thanks! I think this can be considered closed.