Added damping_factor property to the ScrollContainer for better deceleration control on touchscreen devices

[mbrlabs]

Why

On touchscreen/mobile devices the ScrollContainer behaves differently then on Desktop. It keeps scrolling based on the input velocity (swipe up/down/left/right) of the user. But unlike one would expect it's barley slowing down when the user stops scrolling. This feels really weird when you are used to the bahaviour of native apps which decelerate much faster. This PR adds the ability to define how fast the list should slow down when decelerating.

I'm not sure if this change would warrant a formal proposal, because for me this feels more like a bugfix anyway. 😄

How

It works by lerping drag_speed towards Vector(0.0) based on the new property damping_factor. A value of 0.0 does not change the speed at all. A damping value of 1.0 stops the scrolling instantly when the user stops scrolling. A value of 0.25 felt like a native Android app in my opinion, so i set the default to that. 0.05 feels like the current behaviour. If this PR is considered an unacceptable breaking change for 3.x i can default to that value instead.

Demo

This is how the ScrollContainer behaves without this PR. Just a slight swipe scrolls through the entire list.

vanilla.mp4

Here i used a damping_factor of 0.25 on the same list (i tried to swipe with the same speed as in the video above):

damped_0.25.mp4

[Calinou]

To me, it feels like we should change the damping factor to match the Android and iOS default automatically instead. This will likely require a lot of empirical testing to get right, but I think it's better than providing a property that uses a "wrong" value by default.

[mbrlabs]

Do you mean getting some kind of value programatically through the Android/iOS APIs or through empirical testing? Because automatically getting a single value won't be enough as Android/iOS probably use different algorihms for deceleration.

But i think you mean through manual testing in which case I agree. I can make a 3.x backport later for easier testing.

[Calinou]

Do you mean getting some kind of value programatically through the Android/iOS APIs or through empirical testing? Because automatically getting a single value won't be enough as Android/iOS probably use different algorihms for deceleration.

Indeed, we will need one value per OS. This value could be overriddable with a project setting using feature tags, but I don't think it should be a per-node property as we have a lot of properties in ScrollContainer already. Do native Android/iOS apps use different scroll damping factors at times?

[mbrlabs]

Do native Android/iOS apps use different scroll damping factors at times?

Not that i know of. Maybe if you use custom list view / recycler view alternatives. It's probably possible to customize native list views to some extend but that's not common.

I don't think it should be a per-node property

Yeah, there is probably no good reason that different ScrollContainers have different damping values. I already added a project setting for that in this PR, so that's just a matter of removing the property from the node.

[KoBeWi]

I didn't look into the code, this PR sounds like it might be related: #47931

[mbrlabs]

@KoBeWi indeed. The deceleration part looks similar to my implementation + it adds a bunch of more features and bugfixes. Maybe we should focus on getting that PR merged instead?

[KoBeWi]

Yeah I'd focus on that PR first. It needs someone to review it.