Network and rendering latency are the usual cause of a broken sync window

What it is

Synchrony problems usually come from pipeline latency, not haptic design errors. Haptics often wait for a remote event to be confirmed, and that confirmation crosses a network round trip plus render queuing. On-screen animation can start early; haptics can only wait for the real event, so the two have different time bases.

Why it happens

The sources stack: local render latency, input sampling period, network round trip, and server processing. Visual feedback is often produced locally by prediction or optimistic update and looks instant; haptics tied to the acknowledgement carry the entire round trip, and the difference between the two is the perceived offset. Jitter hurts more than mean delay: a stable delay can be compensated in advance, while random variation cannot be covered by any single compensation value and must be absorbed as design tolerance.

Studying it

Measure at two levels: instrument the pipeline with per-stage timestamps to localize where delay accrues, and use synchrony judgment tasks to measure the offset users can detect. Comparing the two shows whether a perceptual problem is caused by the pipeline. Variables include network conditions (delay, jitter, loss), render load, and device type. Include a jitter metric, since it constrains any compensation strategy.

Where it stops holding

With local prediction, users usually perceive no delay, but when a prediction fails and rolls back, a violent misalignment appears—an occasional event that damages trust more than steady latency. Fully offline systems have no network component, leaving render and sampling latency. Compensation also has a ceiling: once delay exceeds perceptual tolerance, any compensation can only shrink the offset, not remove it.

Applying it

• Bind haptics to locally determined event moments rather than to the arrival of a remote acknowledgement.
• When waiting for the remote is unavoidable, give an immediate local confirmation and treat the remote result as a later state update.
• Monitor jitter, not just mean delay, and design tolerance for jitter rather than a fixed compensation.
• Verification: under weak network and high load, measure both end-to-end timestamps and the offset users detect, confirm the main source is localized, and check jitter is within design tolerance.

Related

• Within the group: D3.04.2 De-synchronization weakens the sense of direct manipulation · D3.04.3 The window width varies with how sensitive the task is to causality
• Adjacent: D1.01.2 When results cannot be immediate, confirm the input was received first · I3.02 Optimistic updates and rollback under network latency
• Search terms: render latency · network jitter · predictive feedback