Repository navigation
iOS SmoothPointerDataDispatcher adds an extra frame of pointer latency #190917
Description
Description
On iOS, SmoothPointerDataDispatcher may hold the latest pointer packet until VSync to smooth irregular input delivery.
However, the pending packet is currently released from a secondary VSync callback, after the primary frame callback for that VSync has already been scheduled.
As a result, pointer data synchronized to VSync N cannot affect the frame associated with VSync N. If processing that pointer data requests a frame, it instead waits for VSync N+1.
This adds an additional display interval to the input-to-render path and is noticeable as increased pointer/scroll latency on iOS.
Current behavior
VSync N
→ BeginFrame N
→ release pending pointer
→ pointer processing requests a frame
→ wait for VSync N+1
Activity
mbcorona commentedon Aug 11, 2026
Thanks for the report and Pr linked @MTtankkeo .
Routing to the iOS team for evaluation.
cbracken commentedon Aug 13, 2026
/cc @cbracken
I've got a (probably pretty stale) patch for this that I wrote back in April to solve #110431, which this issue may be a dupe of. I'll compare the two issues. (iOS triage meeting)
cbracken commentedon Aug 17, 2026
@MTtankkeo before I get started reviewing your patch, can you take a look at #110431 and let me know if this is a dupe of that bug? To me this looks related but separate at first look.
As mentioned, back in April I started on a prototype patch for this, but like yours it touches some very sensitive threading/synchronisation code in the embedder and needs a lot of time to make sure that (a) it's correct and (b) it won't cause problems with the current work migrating the embedder towards the embedder API.
@knopp and I both took a quick initial look at your patch last week, but just a quick heads-up that due to the complexity of that code, I expect review/experimentation with it to take some time.
cbracken commentedon Aug 17, 2026
Okay looking at this a bit more; this is actually separate.
SmoothPointerDataDispatcheris tacking on an extra frame of latency since we hold the incoming packet and then release on a secondary vsync callback after BeginFrame was already queued.Then we hit #110431.
Alright let me dig into
SmoothPointerDataDispatcher. A lot of the detailed history/rationale for that is internal and tangentially Fuchsia-related. I'd like to understand whether any of the issues that led to it are even still valid int the current post-thread-merging world.jmagman commentedon Aug 21, 2026
Thanks for your thorough investigation! We'll keep looking into this issue here #110431 (309 👍) and are actively working on a fix. Please follow along there for updates!
Cleanup VSync infrastructure and improve iOS touch to present latency (…
Cleanup VSync infrastructure and improve iOS touch to present latency (…