You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: HG 2.1 Reported for operating system, platform: Other, x86
Comments on the original bug report:
On 2016-09-21 17:47:09 +0000, Eric Wasylishen wrote:
Created attachment 2566
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.
On 2016-09-21 23:45:02 +0000, Martijn Courteaux wrote:
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.
On 2016-09-24 16:31:13 +0000, Alex Szpakowski wrote:
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+.
On 2016-09-24 17:13:03 +0000, Martijn Courteaux wrote:
@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.
On 2018-03-09 03:01:52 +0000, Eric Wasylishen wrote:
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?
On 2018-03-09 03:06:03 +0000, Eric Wasylishen wrote:
Created attachment 3190
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.
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.
On 2018-03-12 04:40:45 +0000, Eric Wasylishen wrote:
Thanks! I think this can be considered closed.
The text was updated successfully, but these errors were encountered:
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
proposed fix (scrollwheel.patch, text/plain, 2016-09-21 17:47:09 +0000, 590 bytes)Reported in version: HG 2.1
Reported for operating system, platform: Other, x86
Comments on the original bug report:
On 2016-09-21 17:47:09 +0000, Eric Wasylishen wrote:
On 2016-09-21 23:45:02 +0000, Martijn Courteaux wrote:
On 2016-09-24 16:31:13 +0000, Alex Szpakowski wrote:
On 2016-09-24 17:13:03 +0000, Martijn Courteaux wrote:
On 2018-03-09 03:01:52 +0000, Eric Wasylishen wrote:
On 2018-03-09 03:06:03 +0000, Eric Wasylishen wrote:
On 2018-03-11 05:15:18 +0000, Sam Lantinga wrote:
On 2018-03-12 04:40:45 +0000, Eric Wasylishen wrote:
The text was updated successfully, but these errors were encountered: