Fix broken scrolling behavior on iPad.

[WolfLink]

With the previous behavior, the trackpad was completely broken: all but the sharpest scroll gestures would result in the translation delta being truncated to 0.

I believe the value from translationInView, which is already a value in units of pixels, should not be scaled at all. I also modified the way that currentScrollTranslation is updated to avoid losing small movements to truncation rounding errors.

This resulted in much better behavior.

I did most of my testing with the trackpad on the Apple Magic Keyboard for my iPad, as well as a USB mouse with a scroll wheel.

[cgutman]

This change made scrolling way too fast on my iPad Pro Magic Keyboard case (tested by scrolling the same webpage in Moonlight vs Safari locally) with a Windows PC using Sunshine nightly.

What is your host OS and software (GFE/Sunshine)? The high resolution scrolling behavior differs by host software and version, so you may just be seeing brokenness due to that issue rather than the client itself.

With the previous behavior, the trackpad was completely broken: all but the sharpest scroll gestures would result in the translation delta being truncated to 0.

Truncation to zero is expected until enough of a translation gesture delta accumulates to generate a non-zero scroll motion. That's why we don't update lastScrollTranslation until enough of a delta is accumulated.

I made an adjustment in 7df349ad7c6669ded659b84bbf75b09332d759dd to improve the smoothness of high resolution scrolling by avoiding jumping 20 unit increments, so maybe that will improve the behavior you saw too.

[WolfLink]

I’ll take a look at your build. I’ve been testing with iPad Magic Keyboard and Ubuntu with Sunshine. I have windows set up with GFE I can try as well.

I thought the problem was on the iPad side because I monitored the scrolling commands being sent and it was almost all 0s even if I was scrolling a lot on my iPad.

Also scaling the scroll amount by the view size seems wrong to me because the magnitude of the scroll input doesn’t vary by view size.

[cgutman]

I thought the problem was on the iPad side because I monitored the scrolling commands being sent and it was almost all 0s even if I was scrolling a lot on my iPad.

I wonder if you were experiencing the bug fixed by https://github.com/LizardByte/Sunshine/pull/1976

Also scaling the scroll amount by the view size seems wrong to me because the magnitude of the scroll input doesn’t vary by view size.

Yeah, that's quite possible. These pixel deltas are just incredibly annoying to translate into regular scroll events.

Do you know if those deltas adjusted by the content scale factor?

[WolfLink]

I wonder if you were experiencing the bug fixed by https://github.com/LizardByte/Sunshine/pull/1976

It definitely was this. Using the current App Store version, I went back and checked with Windows/GFE and scrolling worked and I built Sunshine from nightly and scrolling then worked as well. My changes only fixed the problem for me because the ramped up scrolling speed worked around the bug in Sunshine. I think there's also an aspect of personal preference - I think that the current scrolling behavior is rather slow.

I still think scaling by the view size is probably wrong. In particular, it seems weird to scale X and Y axes differently in this way.

Do you know if those deltas adjusted by the content scale factor?

From my read of the documentation, I think it probably should be affected, but when I went to experiment, I found that it seems the Moonlight StreamView always has a contentScaleFactor of 1 regardless of System settings or which device I am using, so the point may be moot.

Unfortunately, the Apple documentation doesn't really specify how the scroll amounts are computed, and experimentation seems to show there are some acceleration effects included, making it even harder to interpret.

What if we change the scaling to a constant, or even a user-customizable value?