Closed watermelonwolverine closed 3 months ago
That's... fascinating, lol. I'll look into it, thanks.
More info: This also happens when panning is set to 3 fingers. In this case I would expect no changes in zoom as the distance between the two touches does not change. Instead, I zoom closer and closer.
Just released v2.2.7, with a different zoom logic and better gesture end detection. I expect this issue to be solved, but let me know if it is not.
I doesn't keep zooming in, instead it zooms in and out while moving the finger left and right. Also, is seems that the zoom sensitivity is now being ignored and it even zooms on a zero sensitivity.
https://github.com/user-attachments/assets/a367aee6-50ce-466d-8423-2fea1125f4a5
https://github.com/user-attachments/assets/836426ad-fabb-4223-9889-0ff9b6e96a82
Is there a threshold that the distance between the touches needs to pass before it starts zooming or does it always start zooming right away?
I had a quick glance at the commit you mentioned up there. Do you take the real world screen size into account during your calculations or are you using pixel distances? It's been a while since I implemented any gesture controls but if I remember correctly I always took into account how big the screen is, especially for things like thresholds. 100px on a FHD monitor with 27" are just too different from 100px on a 4k tablet with 12" for example.
I did kinda remove the sensitivity option there. The reasoning is that the new logic is not multiplicative anymore: I basically just take the "world distance" between the two fingers and try to keep that constant. There is a (hard-coded at the moment) threshold to actually change the scale, but I might need to calibrate it a little better before using it as a sort of sensitivity setting. Nothing in the logic is based purely on pixel distance, as far as I can tell.
What I plan to do: instead of having a hard threshold for the scale change (which causes the jittering you see there), I'll see if I can ease the change a bit. You will still notice changes in the zoom value, but it will be smoother.
Can I ask why you're swiping two fingers together like that, though? A lot of the behavior we are addressing here is due to having very small numbers involved in the calculation. If your fingers are 20px apart, and during that quick swipe that distance fluctuates by even just 5px, that's a 25% change in zoom.
I could also add some kind of detection of how close the two fingers are, which would help in your case. But that would have to be based on pixel distance (like the old 100px I had in the previous version), since I don't think there's a reliable way to calculate a real-world distance on the screen.
Can I ask why you're swiping two fingers together like that, though? A lot of the behavior we are addressing here is due to having very small numbers involved in the calculation. If your fingers are 20px apart, and during that quick swipe that distance fluctuates by even just 5px, that's a 25% change in zoom.
I did it this way because it makes it easier to keep the distance between the two touches relatively constant. I assumed that the change in distance between the two fingers had to exceed a certain threshold to activate the zoom mode.
My suggestions would be (and you are free to ignore them):
I agree with most of that, and I'll definitely have to think about it a little bit. Some notes, mostly as a way of collecting my own thoughts in the meantime I guess:
The "either zoom or pan" mode feels to me like it's basically already there as an option (two-fingers zoom, three-fingers pan); while adding different configurations could be valuable, I don't think I would remove the two-finger combo gesture anyway (I know I use it a lot).
Basing the gesture decision on actual distance would be great, but I'm conflicted about what kind of info to ask the user. I'm also considering the wild idea of having a little gesture calibration window in the settings, but... that might be a lot. I'll update here when I have news.
Yes, I think you're right. The either "zoom or pan" suggestion made too many assumptions on the users' wishes, Also, if the threshold is working consistently I think there is no reason for those to states to exclude each other. I agree, a calibration tool would indeed be nice.. and probably a lot of work. It could be an image of something everybody has, like a credit or debit card, and a slider. The user could then use the slider to adjust the zoom of the image until it fits the real object. For now I think I a simple configuration option to set the pixel-value thresholds would be good enough.
So, I added a little calibration tool to TouchVTT's settings in the latest unstable. It doesn't mention pixel values directly, but it gives a couple of 1-100 sliders and lets the user try it out live. Under the hood, the "sensitivity value" from the slider is just translated to actual thresholds, where 0 means "disabled" and 100 means no threshold at all. Let me know what you think, I'd like a second opinion before bringing it to the live version.
Then again, making small zoom changes might be harder that way as you'll always have to zoom out to exceed the threshold and then back in again to get the zoom you want. I guess we can conclude that for devices with low DPI touch gestures can only become so good until they hit the limit of the hardware. In the end you already implemented the 3 point pan is there to solve that. Using three fingers is not as nice as using two but if the tech can't adapt the human must.
Yeah, the zoom starting point choice was a bit of a head-scratcher. I went with the point where the threshold was reached because I really disliked the zoom jump; the latest unstable uses the mid-point between the two options to alleviate some of the negatives (and is available to all players and has the label you suggested). I'll test it a bit and then it should be ready to go live.
I'll mark this as closed with 2.2.8. Let me know if you have other issues with the calibration.
Panning with two fingers also zooms.
https://github.com/user-attachments/assets/1cb1b745-563b-48af-93f8-113b98ce6caa