Improve fling gestures on iOS#2851
Conversation
Removed unnecessary adjustment logic for sample count.
| if (dataPoints[sampleCount - 1] < dataPoints[0] && velocity < 0) { | ||
| return 0f | ||
| } | ||
| if (dataPoints[sampleCount - 1] > dataPoints[0] && velocity > 0) { | ||
| return 0f | ||
| } |
There was a problem hiding this comment.
I think this is a wrong logic: it is a normal situation when user does two-directional gesture by their intent. We need to detect only one point mistakes (as you showed).
There was a problem hiding this comment.
To be honest, I still think we don't need to do that at all
There was a problem hiding this comment.
The investigation showed that fixing the "one point mistake" cannot fix the expected behavior of the gesture. There are several reasons: It can be more then one point the goes on the opposite direction from the gesture direction and on 120 fps the density of events is higher (or very low in case of lags) - this approach cannot be applied in such cases.
The goal of this MR to align behavior between native iOS and Compose scrolls. Tests show that current logic helps more closely mimic the iOS scrolling experience. We can either make this behavior multiplatform or move it to the iOS codebase.
My vote here for Multiplatform solution: scroll behavior for browsers on iOS also need to be aligned with iOS experience.
There was a problem hiding this comment.
Could you implement a pure swift app with a scroll view + touch points tracking and show how it works on iOS?
There was a problem hiding this comment.
This should be more clear - here are 2 examples of gestures for iOS scroll view that finished with full scroll stop. Both are long gestures:
Gesture 1 (have points in opposite direction from general scroll):
[event] began point=(198.3, 602.3)
[event] moved point=(196.0, 586.3) dt=0.029s
....
[event] moved point=(219.3, 467.7) dt=0.129s
[event] moved point=(220.3, 464.0) dt=0.145s
[event] moved point=(221.0, 463.7) dt=0.162s
[event] moved point=(222.0, 466.0) dt=0.196s // Compose will inserts synthetic move after this event
[event] ended point=(224.3, 468.0) dt=0.196s
Gesture 2 (points in the same direction, but slowing down):
[event] began point=(172.7, 602.0)
[event] moved point=(168.0, 581.3) dt=0.047s
...
[event] moved point=(189.0, 348.7) dt=0.213s
[event] moved point=(189.7, 345.7) dt=0.230s
[event] moved point=(192.3, 345.3) dt=0.247s
[event] moved point=(193.3, 345.3) dt=0.264s // Compose will inserts synthetic move after this event
[event] ended point=(195.3, 344.3) dt=0.265s
…nter/util/PlatformVelocityTracker.ios.kt Co-authored-by: Vendula Švastalová <vendula.svastalova@jetbrains.com>
…nter/util/PlatformVelocityTracker.ios.kt Co-authored-by: Vendula Švastalová <vendula.svastalova@jetbrains.com>
Move `WebVelocityTracker1D` to the skiko source set and rename it to the `PointerVelocityTracker1D`. Add `preventReversedPointerMovements` option that prevents velocity tracker from returning velocity with the opposite direction to the general scroll direction. Fixes https://youtrack.jetbrains.com/issue/CMP-9297/Fling-gestures-not-working-correctly-in-LazyColumn-on-iOS. ## Release Notes ### Fixes - iOS - Fix the scrolling inertia issue when performing short scroll gestures. - Fix an issue where a fling may occur unexpectedly when lifting a finger. --------- Co-authored-by: Vendula Švastalová <vendula.svastalova@jetbrains.com>
Move
WebVelocityTracker1Dto the skiko source set and rename it to thePointerVelocityTracker1D.Add
preventReversedPointerMovementsoption that prevents velocity tracker from returning velocity with the opposite direction to the general scroll direction.Fixes https://youtrack.jetbrains.com/issue/CMP-9297/Fling-gestures-not-working-correctly-in-LazyColumn-on-iOS.
Release Notes
Fixes - iOS