Latency
More actions
Latency in virtual reality (VR) and augmented reality (AR) is the delay between an input or physical event and a corresponding system response. Motion-to-photon latency (MTP) measures the delay between movement of a tracked object and its visual representation on a display. Head movement, controller movement and changes in the camera view can follow different processing paths, so a headset does not have one latency value that describes every interaction.[1]
Delayed visual feedback can affect interaction and presence, and latency can contribute to cybersickness. The magnitude and perceptual effects depend on the movement, application, display and timing behavior. In AR, delayed virtual imagery can also move out of alignment with real objects. Useful latency measurements therefore identify their starting event, output endpoint and test conditions.[2][3]
Motion-to-photon latency
An end-to-end measurement compares a physical event with the light produced by the corresponding display update. It includes delays in sensing, communication, tracking, application processing, rendering and presentation. Measuring only the time spent rendering a frame, or the interval from an API call to presentation, leaves out parts of that path.[2][4]
For an event-based test, latency is the time of the visible response minus the time of the physical event. Continuous-motion tests instead compare trajectories, for example by estimating a phase shift between real and displayed motion. These approaches can give different results when the system uses predictive tracking. A predictable movement may be displayed with little apparent lag even though the physical processing pipeline still takes time.[5]
Distinguishing feedback paths
| Measure | Starting event and output | Interpretation |
|---|---|---|
| Head motion-to-photon | Head movement to the corresponding displayed viewpoint | Specify rotation or translation, movement profile and location measured on the display. A compositor may update the viewpoint after application rendering.[6] |
| Controller motion-to-photon | Movement of a tracked controller to the corresponding visible movement | Does not measure button response or necessarily share the head-view correction path.[5] |
| Hand tracking delay | Physical hand movement to estimated hand or finger data; alternatively, movement to a displayed virtual hand | A comparison of tracking data with a reference motion capture system is not automatically a measurement of display emission.[7] |
| Eye-to-image latency | Eye movement or eye-camera capture to the resulting gaze-dependent display change | Includes eye tracking and the image-update pipeline; relevant to foveated rendering.[8] |
| Passthrough photon-to-photon | A change in light in the environment to its appearance through the headset camera and display | Measures the real-world video path, distinct from virtual-content head motion-to-photon.[9] |
| Interaction-to-haptic or interaction-to-audio | A physical or virtual event to vibration, force or sound output | Separate hardware and software paths can give different delays, creating audiovisual or visual-haptic asynchrony.[10] |
Latency also differs from spatial tracking error. A pose can be late but accurate for its timestamp, or timely but spatially inaccurate. Motion prediction introduces another distinction: its displayed pose estimates a future state rather than reporting a newly measured physical state. Calibration and temporal alignment both matter when comparing a tracked hand or object with a reference.[4][7]
Types and sources of latency
Components of the latency pipeline
The processing path includes both computation and waiting for other components. Overlapping pipeline stages make high throughput possible, but throughput alone does not establish how old the displayed input is. Buffering and synchronization can add delay even when a stage finishes its work quickly.[2]
| Stage | Sources of delay | Measurement or optimization consideration |
|---|---|---|
| Sensor acquisition | Sampling intervals, camera exposure and readout | Use the measurement timestamp, rather than treating data arrival as the moment the physical event occurred.[11] |
| Tracking and sensor fusion | Motion estimation, filtering, transport and processing of older measurements | Newer inertial data can update a pose before the next camera-based correction becomes available.[11] |
| Application simulation | Input sampling, physics, interaction logic and thread scheduling | A visually updated controller and a collision response can use poses from different points in the frame.[5] |
| CPU and GPU rendering | Command generation, GPU work, synchronization and queued frames | Profile both application and compositor work, including missed submissions and GPU scheduling effects.[12] |
| Compositing and correction | Image distortion, overlays, reprojection and frame synthesis | The displayed head pose may be newer than the application image; scene animation and interaction responses may remain older.[6] |
| Transmission and display | Image transfer, display buffering, scanout and pixel illumination | Identify the measured display location and whether the endpoint is the first, middle or another scanline.[13] |
Sensor and tracking latency
An inertial measurement unit supplies angular velocity and acceleration observations. High sampling frequency helps provide recent observations, but the sampling interval is not the complete sensor-to-display delay. The historical Oculus Rift Development Kit tracking paper reported inertial observations at 1,000 Hz and separately discussed transport, fusion, simulation, rendering and video output. It also distinguished estimating present orientation from forecasting the orientation needed when an image becomes visible.[4]
Camera images represent exposure intervals, and their age depends on the timestamp convention. Daniel Wagner's 2018 DAQRI pipeline explanation used a hypothetical 20 ms exposure timestamped at its midpoint: the image was already 10 ms old when exposure ended, before another assumed 5 ms of readout. Those values illustrate pose age in that example; they are not measurements of every inside-out tracking system. Integrating subsequent IMU observations can bring an older camera-based estimate forward, with limits from noise and drift.[11]
The visual hand model has its own detection and estimation stages. In a Quest 2 study published online in 2023, Abdlkarim and colleagues compared hand data with Qualisys motion capture for eight volunteers performing reaching and hand opening tasks. The headset, running build 33.0, was fixed above the participant's head and connected through Link to a custom Unity environment. For reaching, the authors reported a mean absolute tracking delay of 45.0 ms, obtained by adding a 7 ms reference-system correction to the measured relative delay of 38.0 ms. The correction came from a cited Qualisys latency test. This was a comparison of tracking data in that configuration, with participants limited to light skin tones; it did not measure emitted light from a displayed hand.[7]
Display latency
Refresh rate describes the number of display refresh cycles per second. The reciprocal gives the nominal interval between refreshes. For a rate f in hertz, this interval is 1,000 / f milliseconds. The following values are arithmetic conversions, rather than headset latency measurements:
| Refresh rate | Nominal refresh interval |
|---|---|
| 60 Hz | 16.67 ms |
| 72 Hz | 13.89 ms |
| 90 Hz | 11.11 ms |
| 120 Hz | 8.33 ms |
| 144 Hz | 6.94 ms |
The interval establishes a timing budget, but it does not give the total age of a displayed pose. The OpenXR specification allows the predicted application display period to differ from the hardware refresh cycle. Runtime frame pacing, queued work and reprojection affect when an application frame is displayed.[14]
Pixel transition time, scanout and persistence are separate properties. Transition time concerns a pixel's change in output; scanout concerns delivery or updating of different parts of an image; persistence concerns how long an image remains illuminated. Low persistence can reduce the blur produced while the eyes move across an illuminated image. It does not remove upstream sensing or simulation delays. An OLED or LCD label alone therefore does not determine end-to-end latency.[15][11]
Rendering latency
The renderer may finish a frame at a high rate while still displaying old input. Multi-stage rendering separates application simulation, CPU command submission, GPU execution and compositor presentation. Avoiding unnecessary queued frames and supplying a recent pose close to rendering can reduce the delay along this path. Front-buffer rendering is a historical approach that draws to the buffer read by the display; it requires careful synchronization between rendering and scanout.[15]
SteamVR's advanced frame timing graph separates CPU and GPU work and records events such as late starts, dropped frames and reprojection. Its application CPU graph does not capture every parallel task on other threads. GPU timings can include scheduling overhead, idle gaps or competing work. These distinctions help locate a bottleneck, but a low value in one graph is not proof of low motion-to-photon latency.[12]
Human perception and physiological effects
Perception thresholds
Latency detection is a task-dependent measurement. In a detection experiment, a point of subjective equality (PSE) identifies the stimulus level at a 50% detection rate. A just-noticeable difference (JND) is the stimulus change needed to move that rate by 25 percentage points. These fitted measures depend on the experiment and cannot by themselves establish a maximum acceptable system delay. In Jerald and Whitton's 2009 scene-motion study, six analyzable participants viewed a projected scene through a modified HMD casing while making prescribed head yaws. Across participants and head-acceleration bins, the mean latency JND was 16.6 ms and the smallest was 3.2 ms. The mean PSE was 38.9 ms. The authors explicitly limited transfer to different contrast, fields of view, experience and motion conditions.[16]
The frequently quoted 20 ms target also appears in historical engineering guidance. John Carmack's 2013 essay recommended reducing absolute head-view delays to approximately that level. This recommendation is useful context for latency optimization, but it is not a formal universal perceptual or comfort standard.[17][16] Michael Abrash's 2014 presentation described 20 ms motion-to-last-photon as working for Valve's prototypes and suggested 25 ms might be sufficient. He also treated presence as depending on several display, optical and tracking properties, rather than latency alone.[18]
Waltemate and colleagues studied a different question in 2016: ten participants copied upper-body movements while viewing a full-body virtual mirror in a CAVE. Avatar feedback had total delays of 45, 75, 125, 210 or 350 ms; the tracked-glasses perspective was not delayed. Motor accuracy worsened between 75 and 125 ms, while reported agency and body ownership declined later. The simultaneity comparison between 75 and 125 ms was a statistical trend, rather than a significant result in that pairwise test. These findings concern delayed avatar feedback during their movement-copying task, not a 75 ms head-view threshold for all VR.[19]
Simulator sickness and cybersickness
Delayed responses can create disagreement between visual feedback and motion cues. Sensory mismatch is one explanation for cybersickness; other theories include postural instability and rest-frame accounts. The symptoms and their relationship to latency depend on the system and exposure. A latency number alone cannot predict an individual's symptoms or guarantee a comfortable experience.[1]
Timing variation also matters. In a 2018 HTC Vive search experiment, Stauffert and colleagues analyzed a final sample of 45 participants, comparing a group with injected HMD tracking jitter against a group without it. After excluding four high baseline sickness scores, their analysis found an effect on total Simulator Sickness Questionnaire score and disorientation, but not significant differences in the nausea and oculomotor subscales. The experiment supports examining spikes and irregular timing; it does not establish that every variable-delay system is worse than every higher constant-delay system.[20]
Latency reduction techniques
Software techniques
Prediction algorithms
Prediction estimates a pose for the time at which it will be used, rather than simply displaying the most recent measurement. Constant angular velocity and constant angular acceleration were among the models compared in the historical Rift head tracking paper. The prediction horizon and changing motion influence the resulting error. Filtering noisy sensor observations and predicting a future pose are related operations, but a particular filter name does not identify how much visual delay has been removed.[4]
Motion onset, impacts, reversals and stops are useful tests because they can invalidate the trend inferred from earlier samples. In Warburton and colleagues' instrumented controller experiment, the HTC Vive, Oculus Rift CV1, Oculus Rift S and Valve Index were tested with Unity 2019.4 LTS and SteamVR 1.14.16. Mean controller motion-to-photon delays across the tested setups were 21-42 ms at sudden movement onset and 2-13 ms during continuous movement. Prediction reduced apparent delay within approximately 25-58 ms of onset. These are dated controller-translation results, rather than measurements of pure rotational headset latency or a comparison of timewarp implementations.[5]
Late latching and frame scheduling
Late latching supplies newer head and controller transforms close to GPU execution. Meta's Unreal documentation, updated April 2026, describes sampling poses at the end of the render thread and patching uniform-buffer transforms. The benefit depends on how much time elapsed since the earlier pose sample; it is not a fixed reduction of a few milliseconds for every scene. The documented implementation requires Vulkan and Multi-View, and lists engine-specific incompatibilities.[21]
A later visual pose can also differ from the pose already used by gameplay and collision code. Meta describes the possibility of a head or hand briefly appearing through geometry even when earlier gameplay calculations prevent that collision. Improving visual pose timing therefore does not automatically update every simulation decision.[21]
In OpenXR, xrWaitFrame paces the application's frame loop and returns an anticipated display time. xrLocateViews provides views for a requested time, and a later call for the same target can use newer information. A pipelined application should compute its target display time using the predicted time and interval and keep that time consistent across its simulation and rendering stages. These API timing rules support prediction and scheduling; they do not guarantee a particular measured MTP value.[14]
Asynchronous timewarp
Asynchronous timewarp (ATW) reprojects the latest completed image using a newer head pose. It can operate separately from application rendering and update a frame before display even when the application has missed a deadline. In the orientation-only version described in Oculus's 2015 explanation, rotational correction reduces view lag but does not account for translation or advance the animation of objects. Near objects can exhibit positional judder, and moving objects can remain at their earlier state.[6]
Depth-based positional reprojection can also correct viewpoint translation. It still has to handle newly exposed areas that were not present in the previous image. Reprojection thus changes the age of the viewpoint information without necessarily making all content in that image current.[6][22]
Spacewarp and synthesized frames
Asynchronous spacewarp extrapolates scene movement from earlier frames. Oculus's 2016 PC Rift explanation used an example of application frames generated at 45 fps with intermediate output for a 90 Hz display. It described artifacts from rapid brightness changes, repeated patterns, disocclusion and some translucent content. Synthetic frames are estimates of how an earlier scene should appear, rather than newly simulated application frames.[23]
The separate Quest feature, Application SpaceWarp, requires application-provided motion-vector and depth buffers. It permits rendering at half the display rate, with the compositor synthesizing intervening frames. Its implementation has additional work and memory requirements, and incorrect motion vectors can produce artifacts. Meta's guide also warns that controller input latency may remain higher than in an application rendering at the full rate, even when head-view latency is well compensated.[24][22]
Hardware solutions
Sensor acquisition, display electronics and processors affect the available timing budget. Hardware improvements are most useful when they shorten the path identified by measurement, rather than only increasing a component's nominal update rate. A display with fast transitions can still receive an old image, while a renderer with spare GPU capacity may be waiting on synchronization or input.[2][15]
Dedicated processing can shorten a particular feedback path. Apple's technical specification for the M5 Apple Vision Pro, read on 12 October 2026, lists an R1 chip and a 12 ms photon-to-photon latency. That specification describes the incoming-light camera/display path; it does not state that every application reaction, controller input or hand pose becomes visible after 12 ms.[25]
Research prototypes can use tighter coupling than general-purpose products. Peter Lincoln's 2017 dissertation describes a mechanically tracked optical see-through apparatus with FPGA-based post-transmission image correction and a rapidly updated digital micromirror display. Its six-bit grayscale implementation had a characterized average motion-to-photon delay of approximately 80 microseconds, with timing verified using encoder signals, a light sensor and an oscilloscope. The rig and limited correction operation are essential context; this was not a freely moving consumer headset or a general application pipeline.[26]
Measurement methods
High-speed camera methods
A camera can capture a tracked object and its displayed response in a common time reference. Event counting compares the frames containing an onset, reversal or stop. At 240 fps, the nominal sampling interval is approximately 4.17 ms; counting frames does not create arbitrarily finer event timing. Periodic-motion fitting can estimate a phase difference at sub-frame intervals, but depends on the movement model and signal quality.[2]
For an HMD, lenses and the small display area can make it difficult to film the real motion and its virtual representation together. Warburton and colleagues instead used a visible LED on a controller assembly and encoded the application's controller samples in display colors. Matching the camera footage to the recorded colors connected physical positions with samples actually shown by the headset. The technique measures controller movement without treating a desktop mirror window as the final visual endpoint.[5]
Exposure, rolling shutter, camera/display synchronization, screen persistence and event-detection rules affect uncertainty. A result should distinguish variation in the system from variation introduced by sampling or reconstruction. Friston and Steed compared automated frame counting, sinusoid fitting and photodiode-based approaches against a controllable mechanical simulator to examine such measurement accuracy.[2]
Light sensors and electronic instrumentation
Photodiodes or other light sensors detect changes in display output, while an encoder, physical switch or other reference marks the input event. An oscilloscope or synchronized acquisition system compares the signals. The method needs a test stimulus that maps the input to a detectable light change. Sensor response, thresholds and acquisition bandwidth contribute to the measurement and should be documented.[26][2]
Passthrough testing can instead compare an external changing light or clock with its appearance on the headset display. Gruen and colleagues used synchronized cameras and an electronic clock to measure this photon-to-photon path. A head-pose prediction measurement and a passthrough test therefore observe different inputs even when they use the same headset.[3]
Software tools
Software timing tools help identify processing costs and missed deadlines. Their metric names require careful interpretation:
| Tool or metric | What it describes | Important limit |
|---|---|---|
| Oculus Debug Tool and PC Performance HUD | Application timing, compositor timing and latency estimates | The documented App Tracking to Mid-Photon interval begins at the tracking-state API call, not at physical motion. TimeWarp to Mid-Photon uses the later timewarp pose, while Flip to Photon - Start concerns presentation and the first scanline.[13] |
| SteamVR Advanced Frame Timing | Application and compositor CPU/GPU timing, missed presentations and reprojection | Frame timing describes parts of the processing path and scheduling; it is not an external comparison of physical movement with emitted light.[12] |
| Game-engine profiling | Timing of application loops and rendering work | The loop in which tracked data drives an interaction can change its delay. A displayed pose and a gameplay response may have different update timing.[5] |
| CloudXR Framework live network statistics | Pose-to-frame-received timing and its variation | These metrics exclude subsequent dequeue, submission, reprojection and display time, and differ from an external end-to-end measurement.[27] |
Cognitive measurement
Gruen and colleagues' 2020 study compared response times with and without video see-through HMDs and checked the inferred delay against electronic-clock measurements. Sixteen participants performed a rapid button-release task after a displayed circle changed color. The inference assumes that a person's cognitive contribution stays sufficiently consistent across the compared conditions. It offers a way to study timing while a person uses the device, but human variability and baseline-display latency limit interpretation.[3]
Interpreting performance measurements
A published number is most informative when its endpoint and operating conditions are available. Comparisons need to distinguish physical delay from predicted visual response, startup from continuous movement, and minimum values from means or distributions. A test of one movement or display location cannot by itself establish the delay of every XR interaction.[2][5]
Dated measurement examples
| Publication or test | Reported result | Scope and limits |
|---|---|---|
| Warburton and colleagues, online 2022, journal volume 2023 | Mean delays across tested setups of 21-42 ms at movement onset and 2-13 ms during continuous movement | Controller translation with HTC Vive, Rift CV1, Rift S and Index; Unity 2019.4 LTS and SteamVR 1.14.16. Prediction affected the trajectory. Not rotational head latency.[5] |
| Abdlkarim and colleagues, 2023 | Mean absolute hand tracking delay of 45.0 ms during reaching | Eight participants; fixed Quest 2 running build 33.0, Unity and Link, with a 7 ms Qualisys reference correction. Data delay rather than display photon timing.[7] |
| OptoFidelity passthrough test, 14 February 2024 | Approximately 11 ms for Apple Vision Pro | Manufacturer of measurement equipment reported a minimum photon-to-photon value using an LED target and BUDDY 6. Minimums were deliberately selected; this is not a mean, current ranking or virtual-content MTP figure.[9] |
| OptoFidelity angular test, 15 February 2024 | Separate axis-wise latency medians and variation | Robot encoder compared with virtual markers during sinusoidal rotation. This measured virtual-content angular response, distinct from the preceding camera passthrough test.[28] |
Reporting latency and jitter
Repeated measurements can reveal irregular spikes or periodic behavior that an average hides. The 2020 Stauffert review recommends going beyond a single mean when describing latency, including its variability and observed timing patterns. This also helps distinguish a consistently delayed response from intermittent missed deadlines.[1]
| Report item | Why it matters |
|---|---|
| Input and output endpoints | Head rotation, controller motion, tracking-data arrival and camera passthrough are different paths. |
| Movement profile and analysis | Sudden onset, continuous motion and cross-correlation can give different estimates with prediction. |
| Hardware and software versions | Engine, runtime, drivers, refresh mode and processing configuration affect the path. |
| Output location and instrumentation | Scanline location, capture interval and synchronization affect the timing estimate. |
| Distribution and time series | Mean, spread, percentiles, spikes and periodicity describe behavior hidden by one summary value. |
| Prediction and reprojection behavior | A corrected viewpoint can be newer than object animation or gameplay feedback. |
These reporting considerations follow the measurement analyses of Friston and Steed, Warburton and colleagues, and Stauffert and colleagues. Percentile statistics should also identify which interval was sampled: for example, a streaming system's pose-to-frame-received percentiles leave out display presentation.[2][5][1][27]
Special considerations
Differences between VR and AR
In optical see-through AR, the real environment is viewed through optics without a camera-to-display pipeline. Delayed virtual graphics can visibly slip relative to that direct view during head motion. The required alignment depends on motion and the tolerance for spatial error, so a single 5 ms figure does not describe every optical AR task. The low latency display research described above addresses this registration problem through late correction within display hardware.[26]
Video passthrough adds camera acquisition and image presentation to the real-world view. Its delay can be measured independently of virtual-content viewpoint updates. Rendering and warping may keep a virtual object responsive to head rotation while the captured image of a real object remains older. The endpoint distinction is demonstrated by separate optical-camera and virtual-marker tests, rather than by combining their numbers into one headset latency.[9][28]
Network and cloud rendering
NVIDIA CloudXR separates server rendering from client display. Pose information travels toward the renderer and video returns to the client, with encoding, transport and decoding contributing work along the path. High network bandwidth does not remove these processing and synchronization steps.[29]
CloudXR Framework's statistics distinguish pose transmission, frame receipt, dejitter buffering and submission. Its pose-to-frame-received latency is therefore broader than a simple network ping but narrower than physical motion-to-photon. NVIDIA's network guide recommends inspecting high-percentile timing and jitter, while its quality-monitor documentation explicitly excludes display and reprojection time from the network quality interval. These vendor metrics are diagnostics for the documented streaming system, not universal comfort limits.[27][30]
Multimodal latency
Haptic, audio and visual responses have separate output paths. Reducing one delay may leave a mismatch between modalities. In a 2019 research account, a haptic-glove team measured physical taps, actuator vibration, headphone output and screen light using synchronized recordings. The team described how changing audio affected the apparent responsiveness of the haptic feedback; it treated its early three-modality perceptual results as preliminary.[31]
Di Luca and Mahnan's associated two-modality study tested nineteen participants tapping a virtual cube while seeing an articulated hand and receiving fingertip vibration. Visual-haptic simultaneity depended on the order of the signals, and participants tolerated different asynchronies when vibration followed rather than preceded visual contact. The experiment measured the timing of visual and vibrotactile feedback in that tapping task.[10]
Research directions
Low latency research includes prediction, display-side correction and gaze-dependent rendering, each with a different error measure. The most relevant question can be spatial registration, response at a sudden movement, or the visibility of a quality change after an eye movement.[4][26][8]
For example, Albert and colleagues' 2017 foveated-rendering study tested nine participants in an HTC Vive with an SMI eye tracker, comparing three image degradation techniques and several high-quality region sizes. Their HMD experiment found no significant difference among the 0, 10, 20 and 40 ms added-delay conditions. The 80 and 150 ms conditions reduced the acceptable amount of foveation in comparisons with several shorter-delay conditions. They suggested an eye-to-image latency of approximately 50-70 ms could be tolerated under the tested conditions. This concerns detection of foveation artifacts in their scene, not permission to delay head-view updates by that amount or to treat all peripheral content as temporally insensitive.[8]
See also
References
- ↑ 1.0 1.1 1.2 1.3 Jan-Philipp Stauffert; Florian Niebling; Marc Erich Latoschik (2020-11-26). "Latency and Cybersickness: Impact, Causes, and Measures. A Review". Frontiers in Virtual Reality 1: 582204. doi:10.3389/frvir.2020.582204. Retrieved 2026-10-12.
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Sebastian Friston; Anthony Steed (2014). "Measuring Latency in Virtual Environments". IEEE Transactions on Visualization and Computer Graphics 20 (4): 616-625. doi:10.1109/TVCG.2014.30. Retrieved 2026-10-12.
- ↑ 3.0 3.1 3.2 Robert Gruen; Eyal Ofek; Anthony Steed; Ran Gal; Mike Sinclair; Mar Gonzalez-Franco (2020). "Measuring System Visual Latency through Cognitive Latency on Video See-Through AR devices". 2020 IEEE Conference on Virtual Reality and 3D User Interfaces (VR). pp. 791-799. doi:10.1109/VR46266.2020.00103. https://www.microsoft.com/en-us/research/wp-content/uploads/2020/01/ieee_vr_2020___latency.pdf. Retrieved 2026-10-12.
- ↑ 4.0 4.1 4.2 4.3 4.4 Steven M. LaValle; Anna Yershova; Max Katsev; Michael Antonov (2014). "Head Tracking for the Oculus Rift". 2014 IEEE International Conference on Robotics and Automation (ICRA). pp. 187-194. doi:10.1109/ICRA.2014.6906608. https://lavalle.pl/anna/papers/LavYerKatAnt14.pdf. Retrieved 2026-10-12.
- ↑ 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 Matthew Warburton; Mark Mon-Williams; Faisal Mushtaq; J Ryan Morehead (2023). "Measuring motion-to-photon latency for sensorimotor experiments with virtual reality systems". Behavior Research Methods 55 (7): 3658-3678. doi:10.3758/s13428-022-01983-5. Retrieved 2026-10-12.
- ↑ 6.0 6.1 6.2 6.3 Michael Antonov (2015-03-02). "Asynchronous Timewarp Examined". Oculus developer blog. https://developers.meta.com/vr/blog/asynchronous-timewarp-examined/. Retrieved 2026-10-12.
- ↑ 7.0 7.1 7.2 7.3 Diar Abdlkarim; Massimiliano Di Luca; Poppy Aves; Mohamed Maaroufi; Sang-Hoon Yeo; R. Chris Miall; Peter Holland; Joeseph M. Galea (2023). "A methodological framework to assess the accuracy of virtual reality hand-tracking systems: A case study with the Meta Quest 2". Behavior Research Methods. doi:10.3758/s13428-022-02051-8. Retrieved 2026-10-12.
- ↑ 8.0 8.1 8.2 Rachel Albert; Anjul Patney; David Luebke; Joohwan Kim (2017). "Latency Requirements for Foveated Rendering in Virtual Reality". ACM Transactions on Applied Perception 14 (4): Article 25. doi:10.1145/3127589. Retrieved 2026-10-12.
- ↑ 9.0 9.1 9.2 Tommi Björk (2024-02-14). "Apple Vision Pro Benchmark Test 1: See-Through Latency, Photon-to-Photon". OptoFidelity. https://www.optofidelity.com/insights/blogs/apple-vision-pro-benchmark-test-1-see-through-latency-photon-to-photon. Retrieved 2026-10-12.
- ↑ 10.0 10.1 Massimiliano Di Luca; Arash Mahnan (2019). "Perceptual Limits of Visual-Haptic Simultaneity in Virtual Reality Interactions". 2019 IEEE World Haptics Conference (WHC). https://massimilianodiluca.info/publication/di-luca-2019/Di-Luca-2019.pdf. Retrieved 2026-10-12.
- ↑ 11.0 11.1 11.2 11.3 Daniel Wagner (2018-08-20). "MOTION TO PHOTON LATENCY IN MOBILE AR AND VR". DAQRI on Medium. https://medium.com/@DAQRI/motion-to-photon-latency-in-mobile-ar-and-vr-99f82c480926. Retrieved 2026-10-12.
- ↑ 12.0 12.1 12.2 "SteamVR/Frame Timing". Valve Developer Community. 2024-01-21. https://developer.valvesoftware.com/wiki/SteamVR/Frame_Timing. Retrieved 2026-10-12.
- ↑ 13.0 13.1 "Performance Head-Up Display". Meta Horizon OS Developers. https://developers.meta.com/vr/documentation/native/pc/dg-hud/. Retrieved 2026-10-12.
- ↑ 14.0 14.1 "The OpenXR Specification: xrWaitFrame, XrFrameState and xrLocateViews". Khronos OpenXR Registry. https://registry.khronos.org/OpenXR/specs/1.1/html/xrspec.html#xrWaitFrame. Retrieved 2026-10-12.
- ↑ 15.0 15.1 15.2 Freddi Jeffries (2016-03-01). "Virtual Reality – Blatant Latency and how to Avoid it". Arm Community. https://developer.arm.com/community/arm-community-blogs/b/mobile-graphics-and-gaming-blog/posts/virtual-reality-blatant-latency-and-how-to-avoid-it. Retrieved 2026-10-12.
- ↑ 16.0 16.1 Jason Jerald; Mary Whitton (2009). "Relating Scene-Motion Thresholds to Latency Thresholds for Head-Mounted Displays". 2009 IEEE Virtual Reality Conference. pp. 211-218. doi:10.1109/VR.2009.4811025. https://pmc.ncbi.nlm.nih.gov/articles/PMC3095496/. Retrieved 2026-10-12.
- ↑ Bruce Sterling (2013-02-24). "John Carmack's Latency Mitigation Strategies". WIRED. https://www.wired.com/2013/02/john-carmacks-latency-mitigation-strategies/. Retrieved 2026-10-12.
- ↑ Michael Abrash (2014). "What VR Could, Should, and Almost Certainly Will Be within Two Years". Steam Dev Days 2014. https://media.steampowered.com/apps/steamdevdays/slides/vrshouldbe.pdf. Retrieved 2026-10-12.
- ↑ Thomas Waltemate; Irene Senna; Felix Hülsmann; Marieke Rohde; Stefan Kopp; Marc Ernst; Mario Botsch (2016). "The Impact of Latency on Perceptual Judgments and Motor Performance in Closed-loop Interaction in Virtual Reality". Proceedings of the 22nd ACM Conference on Virtual Reality Software and Technology (VRST '16). pp. 27-35. doi:10.1145/2993369.2993381. https://graphics.rocks/publications/2016-latency.pdf. Retrieved 2026-10-12.
- ↑ Jan-Philipp Stauffert; Florian Niebling; Marc Erich Latoschik (2018). "Effects of Latency Jitter on Simulator Sickness in a Search Task". 2018 IEEE Conference on Virtual Reality and 3D User Interfaces. pp. 121-127. doi:10.1109/VR.2018.8446195. https://downloads.hci.informatik.uni-wuerzburg.de/2018-ieeevr-latency-preprint.pdf. Retrieved 2026-10-12.
- ↑ 21.0 21.1 "Enable Late Latching". Meta Horizon OS Developers. 2026-04-14. https://developers.meta.com/vr/documentation/unreal/unreal-late-latching/. Retrieved 2026-10-12.
- ↑ 22.0 22.1 "App Spacewarp". Meta Horizon OS Developers. 2024-08-16. https://developers.meta.com/vr/documentation/spatial-sdk/os-app-spacewarp/. Retrieved 2026-10-12.
- ↑ Dean Beeler; Ed Hutchins; Paul Pedriana (2016-11-10). "Asynchronous Spacewarp". Oculus developer blog. https://developers.meta.com/vr/blog/asynchronous-spacewarp/. Retrieved 2026-10-12.
- ↑ "App Spacewarp". Meta Horizon OS Developers. 2026-04-08. https://developers.meta.com/vr/essentials/app-spacewarp/. Retrieved 2026-10-12.
- ↑ "Apple Vision Pro - Technical Specifications". Apple. https://www.apple.com/apple-vision-pro/specs/. Retrieved 2026-10-12.
- ↑ 26.0 26.1 26.2 26.3 Peter C. Lincoln (2017). "Low Latency Displays for Augmented Reality". University of North Carolina at Chapel Hill, doctoral dissertation, chapter 3. https://sreal.ucf.edu/wp-content/uploads/2018/02/dissertation_lincoln-op.pdf. Retrieved 2026-10-12.
- ↑ 27.0 27.1 27.2 "Network Test and Session Quality". NVIDIA CloudXR SDK documentation. https://docs.nvidia.com/cloudxr-sdk/latest/usr_guide/cloudxr_framework/network_quality.html. Retrieved 2026-10-12.
- ↑ 28.0 28.1 Tommi Björk (2024-02-15). "Apple Vision Pro Benchmark Test 2: Angular Motion-to-Photon Latency in VR". OptoFidelity. https://www.optofidelity.com/insights/blogs/apple-vision-pro-bencmark-test-2.-angular-motion-to-photon-latency-in-vr. Retrieved 2026-10-12.
- ↑ "NVIDIA CloudXR SDK Overview". NVIDIA CloudXR SDK documentation. https://docs.nvidia.com/cloudxr-sdk/latest/overview/overview.html. Retrieved 2026-10-12.
- ↑ "Network Setup". NVIDIA CloudXR SDK documentation. https://docs.nvidia.com/cloudxr-sdk/latest/requirement/network_setup.html. Retrieved 2026-10-12.
- ↑ Forrest Smith (2019-07-18). "Measuring the perception of latency with a haptic glove". Tech at Meta. https://tech.facebook.com/reality-labs/2019/7/measuring-the-perception-of-latency-with-a-haptic-glove/. Retrieved 2026-10-12.