Flutter should use the platform configured touch slop value for Android

[jonahwilliams]

Currently the framework uses a constant kTouchSlop = 18 (logical pixels) for all touch interactions. This has historically been the source of some controversy.

The Android Framework provides a touch slop value via the ViewConfiguration class. This value is in physical pixels (slight guess, though logical pixels are usually referred to as dp/dips).

On my personal Pixel 4 device, querying the view configuration with the following snippet:

Log.i("Flutter", "value= "  + ViewConfiguration.of(getApplicationContext).getScaledTouchSlop());

I get a value of 22. Converting from physical to logical pixels with a dpr of 2.75 gives 8 physicals pixels - less than half the touch slop we currently use.

I believe this discrepancy contributes to some amount of the reported lag, since a flutter list view will feel less responsive than a native list view on the same phone because the scrolling drag gesture will be accepted slightly later on Flutter. At the same time, there may be cases where manufacturers have configured this value higher due to device specific touch input performance.

Reading this value and forwarding to the framework could be done in a similar method to all of the existing view configuration/media query logic. Drag gesture recognizers could be configured to use this value and fall back to the existing constant.

Other platforms may have similar features that we should keep an eye out for.

[jonahwilliams]

There are other configurations we could use besides touch slop, but touch slop is the most prominent. double tap/press timeout should also be investigated

[jonahwilliams]

iOS also has its own values, defined such as https://developer.apple.com/documentation/uikit/uilongpressgesturerecognizer/1616427-allowablemovement

[jonahwilliams]

Proposal:

Add a field to the ViewConfiguration class defined in dart:ui called physicalTouchSlop have the embedders configure this, and default it to null if not provided.

• Add a new widget TouchQuery modeled after media query, which converts the nullable physicalTouchSlop into a dpr based non-null touch slop, using kTouchSlop as a fall back. This class could be expanded to include additional touch configuration in the future.
• Add a new field to the base GestureDetector, platformTouchSlop which defaults to kTouchSlop and can be set during GestureDetector creation.
• Update the GestureDetector widget, along with all flutter widgets which directly construct gesture detectors to set the platformTouchSlop from a TouchQuery.of

Android specific changes:

• Read the physicalTouchSlop via the ViewConfiguration class documented above

iOS specific changes

• Create a GestureRecognizer class and read the allowable movement value, convert from points back to phyiscal pixels for consistency.

[jonahwilliams]

FYI @Hixie @goderbauer for thoughts

[Hixie]

This would be great.

I would just put it on MediaQuery though, no need for a new mechanism. And I wouldn't bother with making it configurable on GestureDetector; people can just change the value on the MediaQuery above the GestureDetector to do that.

[jonahwilliams]

Right, no need to configure on GestureDetector itself, but the sort of raw gesture detection classes are built outside of the widget tree, so they would need to configure them.

I would just put it on MediaQuery though, no need for a new mechanism.

That is my inclination, though I know that @HansMuller has expressed some concern with how MediaQuery it has grown, so I was hedging my bets. I'm happy to go with either approach

[goderbauer]

This would be a good addition to make Flutter apps feel more native on these platforms. I'd also lean towards sticking it into the MediaQuery - maybe as a single entry that exposes an object with all the different touch settings.