Use midpoint of touches for zoom/rotate calculations

[Carifio24]

This PR provides an implementation of the idea discussed in #283 (comment) and the following comment, where the midpoint of the two touch locations is used as the "center point" for calculations, rather than the viewport center.

As discussed there, this allows zooming and rotating from different areas of the screen, although of course the center of these motions is still the viewport center. The implementation here is simple - when a second touch is reported, we calculate the center of the two touches and save that as _twoCenterTouch, then use that in the zoom/rotate calculations. When we go down to < 2 touches, we reset that to null.

@pkgw Would be curious to know what you think. With this, I think the only major difference between our touch controls and what one usually sees (e.g. Google Maps) is that we don't allow rotating and zooming simultaneously.

[pkgw]

I'm find that the scaling is working very intuitively, but something has gone wrong with the rotation control. When I can get it to rotate, the rotation gesture also feels natural, but lots of times it's not getting into "rotation mode" even when I feel that I'm making a very clean "twist" gesture. Do you see something similar?

[Carifio24]

@pkgw I pushed a new commit that recalculates the center point on each touch move and increases the eagerness to rotate just a bit. I think this is an improvement (it feels a bit better to me) but still want to experiment some more, but wanted to push this in case you wanted to try it out.

[pkgw]

I'm still finding that it's quite hard to trigger rotations. Sometimes it seems to get into a "mode" where it feels like I can do so relatively easily (in a series of separate gestures), and other times I keep on making twist gestures and it just refuses to rotate. It's definitely possible that this has something to do with my particular setup (using Firefox on my laptop, which has a touchscreen).

[Carifio24]

I did a bit of experimentation using the remote inspection in Chrome (Firefox doesn't want to recognize my phone, still working on fixing that). I noticed that when I did what I thought was a rotation gesture but nothing happened, it was actually because the zoom flag was set - but nothing was happening visually because I was trying this at the default (full) zoom, and it was attempting to zoom out. Starting with the view zoomed in a bit, I can see small zoom changes when the "rotate" gesture doesn't work for me. Is this something that you notice as well?

[pkgw]

Yes, I think I was seeing the same thing. If I start from a zoomed-in view, it seems like I'm getting the intended behavior of either zoom or rotation, although it still seems to not always enter rotation mode when it really feels like it should.

[Carifio24]

@pkgw I finally got around to revisiting this. I think one of the problems that we were having is one touch move event isn't always enough to cleanly define what sort of motion it is that we're doing. I've updated the approach here to "wait" a certain number of events before deciding whether we're zooming or rotating. Basically, the rectangle that defines the touch movements isn't updated until the specified number of events has passed. Then the first position deltas used are (relatively) much larger, and should give a more accurate impression of whether the radial or angular component is dominant.

This obviously adds another free parameter in terms of how many events to wait. We don't want this number to be too high since that could be noticeable, but it should be enough so that we can properly determine the movement type. I've set the value here to be 10, which seems to work pretty well in my testing.

[pkgw]

I think this is it!!