Reduce iOS pointer latency by dispatching pending input before BeginFrame - #190918

Description

Fixes #190917

On iOS, SmoothPointerDataDispatcher may hold the latest pointer packet until VSync to smooth irregular input delivery.

Previously, the pending packet was released from a secondary VSync callback, after the primary frame callback for that VSync had already been posted.

As a result, pointer data synchronized to VSync N could not affect the frame associated with VSync N. If processing that pointer data requested a frame, the request would instead wait for VSync N+1, adding a full display interval to the input-to-render path.

In other words, the pointer packet was synchronized to one VSync but could only be rendered by the following one.

Changes

This change adds a bounded pre-frame callback phase to VsyncWaiter.

The callback order becomes:

1. A platform VSync fires.
2. Pre-frame callbacks run on the UI task runner.
3. The primary frame callback is consumed and runs.
4. Secondary callbacks run.

SmoothPointerDataDispatcher now releases its pending pointer packet during the pre-frame phase instead of from a secondary callback.

The primary callback is intentionally left available until pre-frame work has completed. If processing the pointer packet requests a frame while the platform VSync has already fired but its primary callback has not yet been consumed, Animator registers that callback synchronously.

This allows the newly requested frame to participate in the current VSync rather than posting AwaitVSync behind the already queued primary-frame task and waiting for the following VSync.

The same-VSync registration window is deliberately narrow. It begins when the platform VSync fires and ends when the primary callback is consumed on the UI task runner. Pre-frame or secondary callbacks registered after the current callback snapshot are kept for the next VSync.

This preserves the existing smoothing behavior of SmoothPointerDataDispatcher. The change only ensures that pointer data released for a VSync can be consumed by the frame associated with that same VSync.

Before and after

Before:

VSync N
  → BeginFrame N
  → release pending pointer
  → request frame
  → wait for VSync N+1

After:

VSync N
  → release pending pointer
  → request/attach frame callback
  → BeginFrame N

The pending pointer packet is still synchronized to VSync, but it no longer incurs an additional frame solely because it was dispatched after the primary callback.

Tests

Added coverage verifies that:

• pre-frame, primary, and secondary callbacks execute in that order;
• a primary callback requested by pre-frame work can join the same already-fired VSync without arming another VSync;
• pre-frame work registered after the current VSync callback snapshot targets the next VSync;
• a packet held by SmoothPointerDataDispatcher is dispatched before the primary callback and can be consumed by the frame associated with the same VSync.

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 documentation (doc comments with ///).
• 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.