mirror of
https://github.com/flutter/flutter.git
synced 2026-02-12 05:42:27 +08:00
29898812d4
Currently the framework uses fairly large "hit slop" values to disambiguate taps from drags/pans. This makes sense on touch devices where the interaction is not very precise, on mice however it can feel as if the UI is lagging. This is immediately noticeable on our infra dashboard, where it takes almost half of a grid square of drag before the actual drag kicks in. One potential solution is to always use smaller constants depending on whether the interaction is mouse or touch based. The only reasonable choice is to use the pointer device kind and not target platform - same platform can have different input sources. This requires exposing the pointer device kind in a few new places in several of the gesture detectors, and using the enum to compute the correct hit slop from an expanded set of constants. This almost works, however there are a few places (notably ListViews) which uses the touch hit slop as a default value in scroll physics. It does not seem like it will be easy to disambiguate a user provided scroll physics constant from the default and/or adjust it somehow - this might require significant changes to scroll physics which I have left out of this PR. This PR does not adjust: kTouchSlop used in scroll_physics.dart's minFlingDistance kTouchSlop used in PrimaryPointerGestureRecognizer/LongPressGestureRecognizer
microbenchmarks
To run these benchmarks on a device, first run `flutter logs' in one window to see the device logs, then, in a different window, run any of these:
flutter run --release lib/gestures/velocity_tracker_bench.dart
flutter run --release lib/gestures/gesture_detector_bench.dart
flutter run --release lib/stocks/animation_bench.dart
flutter run --release lib/stocks/build_bench.dart
flutter run --release lib/stocks/layout_bench.dart
The results should be in the device logs.
Avoid changing names of the benchmarks
Each microbenchmark is identified by a name, for example, "catmullrom_transform_iteration". Changing the name of an existing microbenchmarks will effectively remove the old benchmark and create a new one, losing the historical data associated with the old benchmark in the process.