| Summary: | [patch] macOS 10.12: small scrolls (1 wheel notch) don't generate events | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Eric Wasylishen <ewasylishen> |
| Component: | events | Assignee: | Eric Wasylishen <ewasylishen> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | amaranth72, courteauxmartijn, sezeroz |
| Version: | HG 2.1 | ||
| Hardware: | x86 | ||
| OS: | Other | ||
| See Also: | https://bugzilla.libsdl.org/show_bug.cgi?id=2293 | ||
| Attachments: |
proposed fix
Proposed patch |
||
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. 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+. @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. 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? 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.
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. Thanks! I think this can be considered closed. |
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.