Skip to content
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

separate zooming logic for trackpads #206

Closed
ansis opened this issue Dec 3, 2013 · 7 comments
Closed

separate zooming logic for trackpads #206

ansis opened this issue Dec 3, 2013 · 7 comments

Comments

@ansis
Copy link
Contributor

ansis commented Dec 3, 2013

@kkaefer via #179 (comment)

I was thinking about implementing different zoom behavior when the user uses a trackpad: Since the user is touching directly, we should tie the zoom to the finger movement directly, i.e. not apply transitions in case of trackpad zooming. However, I'm not sure whether it's possible to distinguish trackpads from mousewheels in all browsers. Typically, the deltas for trackpad zoom are much lower, but they can get in the same area as mousewheel scroll deltas when the user zooms fast. Maybe we can do a heuristic detection that puts zooming into trackpad mode when the first couple of mousewheel events have a low (< 40 or so) delta, and in scrollwheel mode when it has high values.

I'm seeing two ways the current mousewheel smoothing isn't ideal for trackpads:

  • Very frequent events may make the transition not speed up fast enough (since the first part of the transition curve is slower).
  • Some trackpads have built-in smoothing at the end of a scroll. This would essentially handle the transition part for you.
@ansis
Copy link
Contributor Author

ansis commented Dec 3, 2013

@kkaefer how big of a priority is this (how bad does the current approach feel on macbooks)?

@kkaefer
Copy link
Member

kkaefer commented Dec 4, 2013

It's very awkward because there is no direct relation between the distance you move your finger and the zooming.

@mourner
Copy link
Member

mourner commented Dec 4, 2013

Leaflet had the same discussion recently, and there was a similar heuristic proposed that seems to work — if the interval between the first two mousewheel events is <40ms, assume a trackpad.

@ansis
Copy link
Contributor Author

ansis commented Dec 4, 2013

I'll leave this for someone else. My trackpad isn't good enough for this to be a problem

I think the distance should be proportional, its just that its delayed. Making the duration of the transition proportional to the delta (or 0 if mousewheel is detected) could fix this: https://github.com/mapbox/llmr/blob/gl/js/ui/handlers.js#L49

Or feel free to disable easing until this is fixed, if its annoying

@kkaefer
Copy link
Member

kkaefer commented Dec 4, 2013

Well, IMHO, the best would be to completely disable transitions for high-resolution trackpads; any sort of easing is weird because you get the feeling that it your touch doesn't immediately control the zoom level, or that the renderer is laggy.

@mourner
Copy link
Member

mourner commented Dec 4, 2013

@kkaefer that's a pretty good idea. I'd love to see how that feels, and maybe try to use the same approach in Leaflet it it's good.

@kkaefer
Copy link
Member

kkaefer commented Dec 4, 2013

Dang, Firefox uses double the scroll amount when the window is on a retina screen...

@kkaefer kkaefer closed this as completed in bc50719 Dec 6, 2013
lucaswoj pushed a commit that referenced this issue Jan 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants