Request unbuffered dispatch for platform view motion events after _PlatformViewGestureRecognizer rejects gesture - #192259

Changes platform view touch input for all modes to request the unbuffered stream for the given event when the GestureArena determines the platform view has bowed out of ownership of that event, via View.requestUnbufferedDispatch(). Flutter content itself makes this request, but currently platform views don't.

This greatly improves platform view scrolling smoothness, while having no breaking change or impact on platform views performing gesture handling (because the GestureArena has determined that they don't own the input event).

Problem & Invariant

Under high-load or scrolling scenarios, buffered touch dispatch causes visible jank and input lag. Flutter requests unbuffered dispatch for its own rendering, but platform views continue using buffered streams unless requested. Simply requesting unbuffered dispatch unconditionally can cause issues if gestures are still competing or owned by the platform view. Scoping unbuffered dispatch to gestures that Flutter has won ensures that platform views receive fast, unbuffered dispatch specifically during Flutter gestures (like scrolling).

Architecture & Gesture Correlation (embedderId)

Previous iterations attempted to correlate gestures across the channel by matching synthetic downTime timestamps packed into PointerDownEvent.timeStamp. However, resamplers or clock drift can alter event timestamps.

Instead, this PR uses Flutter's canonical embedderId mechanism:

1. Android Touch Processor: When an Android MotionEvent arrives, AndroidTouchProcessor tracks it using MotionEventTracker.track(event) and populates packet.putLong(motionEventId), which the framework receives as PointerEvent.embedderId.
2. Framework Arena Resolution: _PlatformViewGestureRecognizer records the embedderId of the pointer-down event. When Flutter wins the arena and calls rejectGesture(pointer), the framework sends gestureId (set to embedderId) over the flutter/platform_views system channel.
3. Engine Correlation (MotionEventTracker.peek):
   • PlatformViewsController and PlatformViewsController2 handle onRejectGesture(viewId, gestureId).
   • The controllers query motionEventTracker.peek(MotionEventId.from(gestureId)) to look up the native MotionEvent without consuming it from the tracker.
   • From this MotionEvent, the native downTime is retrieved and passed to FlutterMutatorView and PlatformViewWrapper.
   • PlatformViewGestureTracker marks flutterWonGesture = true if the downTime matches the current active gesture stream, and keeps calling requestUnbufferedDispatch() for all remaining events in the gesture until ACTION_UP or ACTION_CANCEL.
4. Graceful Degradation / Fails Closed:
   • If peek() returns null (e.g. if the event was already popped or on non-Android embedders), or if gestureId is 0 or unmatched, the optimization degrades gracefully to standard buffered touch dispatch without breaking input handling.

Tests

• Framework tests: packages/flutter/test/rendering/platform_view_test.dart
  • Verifies rejectGesture passes the pointer's embedderId as gestureId.
  • Verifies multi-touch gestures correctly pass individual embedderIds.
  • Verifies no channel call is dispatched when embedderId is 0.
• Engine Robolectric tests:
  • PlatformViewsControllerTest: Verifies rejectGesture with valid gestureId looks up tracked MotionEvent and enables unbuffered dispatch; verifies mismatched or missing IDs do not enable it.
  • PlatformViewsController2Test: Verifies same behavior on the modern hybrid composition pipeline.
  • FlutterMutatorViewTest and PlatformViewWrapperTest: Verifies gesture tracking across ACTION_DOWN, ACTION_MOVE sequences, and resetting on ACTION_UP/ACTION_CANCEL.

Supersedes #192249

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant in-code documentation (doc comments with ///).
• If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in flutter/website (or verified none is needed).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

Generated with Gemini / AI assistance.