-
-
Notifications
You must be signed in to change notification settings - Fork 35.5k
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
OrbitControls: Use scroll event delta to modulate zoom speed #27418
Conversation
Signed-off-by: Guilherme Avila <[email protected]>
Also worth mentioning, I've tried to make it so the default zoom speed is equivalent to what we currently have. But, given that many cases would now respond to possible OS configs and scroll behaviour correctly, users might notice differences. |
This always bothered me. Thanks! |
After this PR, if you zoom by pinching on the trackpad, the zoom barely changed. In contrast to before, you were able to zoom on the scene much more by pinching.
|
Can you inform OS/Browser? @marcofugaro |
Sure, I am on a Macbook Air with Sonoma 14.0, on the latest Chrome 120 |
I do know Mac OS implements built-in damping on their trackpad events, so it is expected that it is slower, for the reasons described in the PR. However, it shouldn't be that slow afterwards. I've modified the It should print some logs on the console, and inform which event is being called and the base amount of delta. I am mostly interested in the initial events (they should have higher values). If you are able to share, perhaps I could identify any problems. If you are also able to share the logs using a mouse, that would be great. |
Sure, here are the logs. The biggest delta is about 15, also note that I was pinching the most width available: I don't currently have a mouse I can hook up to my macbook. |
Eventhough the mode is correct, the values are indeed smaller than I would expect. Those values look more in line with a device with I did some tests on other devices and it did appear like the values were considering the devicePixelRatio for the deltas given, but now I'm unsure. Having both mouse and trackpad logs on the same device, would help me narrow down. But I imagine this problem is mostly related with normalizing the delta based on I will try to investigate this a bit further, thanks for the logs. |
Yeah I can confirm, window.devicePixelRatio on the macbook is 2. |
This proved to be a lot more complicated than I antecipated. There are two problems, one problem is relating to my previous comment, I still haven't found a clear answer if But there is another problem, specifically relating to pinching on trackpads. The default behaviour, outside three is to control the page's scale, this triggers a This pinch I'm kinda baffled by how bad this all is to be honest, I'm starting to realize why we didn't bother using delta in the first place. |
We may need to check the user agent on this one... |
I took a look at Mozilla/gecko-dev, and got some answers here. Their implementation, at least, doesn't consider pixel density for their Now for the trackpad pinch problem, I did find a nice comment explaining how this A crude simplification is that the The only question that remains is how we go about differentiating between this pinch event and a regular wheel event with ctrl-key pressed. And I can only think of one method, but it is not great. Since the pinch event automatically sets Any |
By using eventListener Nevertheless, here is a Live Example of all necessary changes. commit log. If this is approved, I'll make a follow-up PR so we can patch r160. |
The pinching behaviour looks good now! 🙌 asd.mov |
Lets give it a go 👍 |
…27418) Signed-off-by: Guilherme Avila <[email protected]>
Since r160, zooming on a Macbook Pro is as slow as seen in @marcofugaro's comment #27418 (comment) |
Try updating to |
0.160.1 fixes it, thanks. |
This PR is an attempt to normalize zoom-speed across devices & operating systems.
I've noticed that
OrbitControls
zoom implementation leads to different zoom behaviors depending on the device / method of interacting with the module. This occurs because we attempt to normalize the amount that is zoomed on every tick / scroll event (getZoomScale
).While this was probably done in an attempt to circumvent potential differences in the way devices handle scrolling, this ends up having the exact opposite effect. This is quite easy to detect if you ever try zooming on a trackpad, as most operating systems implement a built-in damping system for it. In fact, I'm quite surprised I couldn't find any issues or complaints about this behaviour, as it has been present for many years now.
Every scroll event (or equivalent) provides a
deltaY
to inform the underlying page of the amount that should be scrolled, this allows the page to respond correctly to the event. By ignoring this amount, we are in practice ignoring potential changes in scroll behavior the user might've set in the operating system, as well as making built-in damping systems work incorrectly.When the operating system has a built-in damping system, it does so by triggering extra events with increasingly smaller
deltaY
, but since this amount is ignored, we treat each of these events as a full scroll, which leads to extremelly fast zoom. In fact, this also affects the regular middle-mouse button scroll, if you try it, you'll notice it is extremely fast and hard to control. (Touch events are handled correctly)I believe our current behaviour for middle mouse button scroll can also be improved, but I'll leave this discussion for a follow-up Issue/PR.
Live Example
@Mugen87 @WestLangley @gkjohnson