-
Notifications
You must be signed in to change notification settings - Fork 497
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normalize scrolling speed across browsers/devices #67
Comments
this plugin is no problem on mac. |
Yes, because that plugin seems to be optimized for mac. On windows, scrolling is unbelievably slow. You have to get spasm in your middle finger to get somewhere. |
I mean It's fine for every os. |
The speed is configurable even with Sly, but it isn't consistent. The general issue is the difference between events triggered by normal mouse wheel, and events triggered by stuff like trackpad on MacBooks. Normal mouse wheel triggers one low precision mousewheel event for every 100px that should be scrolled, while trackpad on MacBooks is triggering shit ton of high precision mousewheel events that are instead of pixels notifying about scroll velocity. And the both events are the same, they just have different I remember once browsing the code of that plugin you've linked, and not finding anything useful I'd like. Also, I don't have a MacBook to test & compare this, so I'm relying on 2nd hand observations, documentations, and random articles on the internet. So my understanding of this might be off :) |
It's middlenight in my place, I can't finish it today, but I still find something in code. |
I know. I've read through jquery.mousewheel plugin. As well as some other implementations trying to handle this. None of them were really good. Most of them do a little bit more complicated version of what Sly does, but nothing that would really normalize the inconsistency between events fired by generic mouse wheel and trackpad. jquery.mousewheel seems to be updated since I've last read through it. Gonna look into it when I'll have some time. Maybe there is something brilliant addressing the issue. |
another thing, don't forget refresh your tag of version 1.1.0. |
malihu changed mousewheel code
It's not original edition mousewheel in malihu. |
That doesn't solve the trackpad issue at all. As stated in the issue description:
So on one hand, you have a really high frequency of mousewheel events triggered by trackpad, and than you are amplifying it by dividing velocity which can be as high as Sly is trying to level it down by normalizing delta to be only -1 or +1 per event, which is still not enough, but better than above code. |
So the next iteration on wheel delta normalization. I hope this one is fixing all the issues. The code is in I've set up a quick test page for it here: http://jsbin.com/InAlUh/1 Please test it in all browsers & OSs you have. Especially Macbook trackpad, and normal mouse on MacOS + Chrome. This is only a scrolling test, dragging and touch navigation is irrelevant here. |
Seems to work great Darsain :) I'm gonna implement tomorrow and give it a spin. Edit: Never mind, did it straight away. Works like a charm on my MacBook! |
v1.2.0 landed including the aforementioned fix. Gonna close this one. If more issues come up, feel free to post them here. |
Continuing from PR #57
Sly is scrolling the content by the same amount of pixels/items per one
mousewheel
event.The problem number one is, that this event might be a concatenation of multiple events, if scrolling is happening too fast. This is reflected in
event.wheelDelta
property, which is multiplied by N, where N is the number of concatenatedmousewheel
events. At least that's how it works in like most of the world devices/browsers.The detection of this concatenation is highly problematic, and at the moment I don't know about any 100% reliable way how to do that. Especially considering the inconsistency of this property across devices & browsers:
Old ilustrational table of one scroll event 'up'. Copied from this stakcowerflow question.
I've tried to detect the base
wheelDelta
by doing modulus ofwheelDelta
and[120, 40, 3]
, but that is obviously not 100% reliable. That beign said, it worked in 99% of cases, except Macbook Trackpads (and potentially other similar devices).Mackbook trackpad's
mousewheel
event reporting is something else. The base is3
, but it can go as high as450+
. That is probably because in Mackbooks, this property doesn't report a value that specifies a destination, but rather the scroll velocity that should be used to control the scrolling animation speed.This breaks everything.
I had to revert my attempt to normalize this, because modulus base detection on Macbook would just result into a ridiculous scroll distance per one event. And there is no way around it.
So currently, Sly will move the content by set number of pixels/items per event, disregarding event concatenation altogether. This is still a problem in Mackbooks, as the
mousewheel
event triggered by trackpads has a very high frequency, which results into a really fast scrolling speed, inconsistent with other devices using mouse wheel.Currently, I don't see any reasonable fix for this, and
userAgent
sniffing is not an option.I guess we have to wait until browsers will decide to implement a more standardized
wheel
event. Currently, only FF and IE9 support it.The text was updated successfully, but these errors were encountered: