Why VR feels smooth, sharp, or off
Frame pacing, GPU load, latency, foveated rendering and display persistence are easy to name and hard to feel. Here you can change each variable yourself and watch what it does.
Every experiment here is a simulation. Nothing on this page measures your headset, graphics card or display, and no number is a benchmark.
Frame Timing Lab
Understand
A headset shows a new image every refresh interval. At 90 Hz that is 11.1 ms. The app has to finish each frame inside that window, every time. One slow frame matters even when the average looks fine, because the display keeps its schedule whether the frame is ready or not.
SIMULATION — NOT A HARDWARE MEASUREMENTSimulated: per-frame render times. They come from a fixed formula, not from a GPU, CPU or headset.
Experiment
Average time to produce one frame.
How far individual frames stray from the average.
- On time: finished inside the budget
- Late: over budget by up to one interval
- Missed: over budget by more than one interval
Playback is slowed down so you can read it. Dashed lines mark 1× and 2× the frame budget.
- Frame-time budget
- Average render time
- Slowest frame in the run
- On time
- Late
- Missed
Observe
Apply
Judge a scene by its slowest frames, not its average frame rate. When you tune settings, leave headroom under the budget so the occasional heavy frame still fits.
How this simulation works
- What is simulated
- The render time of each of 600 frames. Refresh rate only sets the budget.
- How outputs are derived
- Budget =
1000 / Hz. Each frame = average + variability × noise, where the noise is a deterministic hash of the frame number, so the same settings always give the same run. With spikes on, about 8% of frames add 0.4 to 1.8 budgets. A frame is on time at or under the budget, late up to 2× the budget, missed beyond that. The run loops while it scrolls. - What you can conclude
- Consistency and headroom matter as much as the average. The same average can look fine or rough depending on its spread.
- What it does not tell you
- What your headset does with a late frame. That depends on the runtime, compositor, headset and application: some systems reuse the previous frame, some reproject it, some lower the app's frame rate. It also ignores CPU/GPU overlap and queued frames.
GPU Resource Explorer
Understand
Each frame the GPU transforms geometry, computes lighting and shadows, samples textures, shades pixels and smooths edges. Some work grows with how much is in the scene. The rest grows with how many pixels are drawn, which is a lot in VR: two eyes, high resolution, every frame.
SIMULATION — NOT A HARDWARE MEASUREMENTSimulated: render cost on a hypothetical reference GPU, from a documented formula. It is not your GPU and not an FPS prediction.
Experiment
100% is the native size of the preview. Pixel count scales with the square.
Drag the scene, or focus it and press the left and right arrow keys, to rotate. The scene is drawn with the browser's 2D canvas: it shows what the settings look like, while the numbers below come from the formula.
- Geometry
- Shadow pass
- Pixel shading
- Relative GPU workload (default setup = 100%)
- Objects drawn
- Particles drawn
- Fits a 90 Hz budget (11.1 ms) in this model?
Largest effect in this simulation (time saved at the lowest setting)
Observe
Apply
When a scene is GPU-bound, render resolution is usually the first setting worth lowering, because it multiplies every per-pixel cost. Treat any estimate like this one as a ranking of ideas to try. Profile the real application on the real machine.
How this simulation works
- What is simulated
- Milliseconds of GPU work on an imaginary reference GPU, split into geometry, shadow pass and pixel shading.
- How outputs are derived
-
objects = 12 to 260,particles = 30 to 700(both from complexity).
geometry = 0.6 + 0.014 × objects
shadow pass = [0, 0.5, 1.2, 2.6][shadow] × (0.4 + 0.6 × complexity)
pixel = 4.0 × scale² × (1 + texture + shadow filter + AA + particle overdraw)
Texture adds 0.05 / 0.18 / 0.35 / 0.60; shadow filtering 0 / 0.08 / 0.22 / 0.45; AA 0 / 0.08 / 0.20 / 0.42 / 0.85; particles up to 0.35. These constants are illustrative choices, not measurements. The ranking re-runs the formula with one setting at its lowest value. - What you can conclude
- Which kinds of work scale with pixels and which scale with scene content, and why raising resolution compounds with other per-pixel settings.
- What it does not tell you
- The speed of any real graphics card. Real cost depends on the card, driver, game engine, scene, thermal conditions and VR runtime. The anti-aliasing zoom shows the idea of coverage sampling. The scene preview itself always uses the browser's built-in smoothing.
Latency Explorer
Understand
Responsiveness is how soon software reacts to an input. Motion-to-photon latency is the whole trip: your movement is sampled, the app updates, the GPU renders, the frame waits in a queue, and finally the display lights up. Each stage adds delay, and you see the total.
SIMULATION — NOT A HARDWARE MEASUREMENTSimulated: every stage duration below is a value you choose. The total is a simple sum, not a measurement of any real headset.
Experiment
- Your input (instant)
- Low-latency reference (20 ms, simulated)
- Object with your simulated delay
While motion plays, drag inside the panel, or focus it and press the left and right arrow keys. The object follows your input with the delay you set. Motion pauses automatically when you prefer reduced motion; press Play motion to start it.
- Total simulated delay
- Largest stage
- Lag at 30°/s head turn
- Lag at 90°/s head turn
- Lag at 200°/s head turn
- Gap on screen right now
Observe
Apply
If a headset feels laggy, ask which stage is the culprit. Developers can shorten application and rendering work. Players can often cut queueing by keeping GPU load below the frame budget. Display delay is mostly set by the headset itself.
How this simulation works
- What is simulated
- Five stages in series: input sampling (fixed at 1 ms here), application processing, rendering, queueing, and display and presentation. You set four of them.
- How outputs are derived
- Total = sum of the stages. The displayed object shows the input position from total milliseconds ago, read from a short history of your input. Head-turn lag in degrees =
degrees per second × total / 1000. - What you can conclude
- Delay is the sum of many small stages, and the faster you move, the more a fixed delay shows up as position error.
- What it does not tell you
- The latency of any real system. Real pipelines overlap stages and use pose prediction, late re-sampling of head pose, reprojection and asynchronous timewarp, which can make perceived delay lower than a plain sum. A commonly quoted rule of thumb is to keep motion-to-photon latency around 20 ms or lower, though tolerance varies by person, content and compensation.
Foveated Rendering Playground
Understand
Your eye sees fine detail only in a small central region. Foveated rendering spends most of its shading effort there and less in the periphery. With eye tracking, the sharp region follows your gaze. Without it, the sharp region stays fixed near the middle of the lens.
SIMULATION — NOT A HARDWARE MEASUREMENTSimulated: a flat picture re-sampled at lower detail away from a point you control. There is no eye tracker and no real rendering pipeline here.
Experiment
Share of full resolution along each axis.
Move the pointer over either image, tap it, or focus it and use the arrow keys to move the gaze point. The cross marks where you are looking. The dashed rings (when outlined) mark where full detail ends and where peripheral quality is reached.
- Relative shading workload
- Shading work avoided (simulated)
- Detail at the gaze point
Observe
Apply
Foveation helps most when pixel shading is the bottleneck at high resolution. Check whether a headset and app use eye-tracked or fixed foveation, and keep the sharp region large enough that the edge of it never becomes noticeable.
How this simulation works
- What is simulated
- A procedural picture, re-sampled in small tiles at one of eight detail levels (100% down to 12.5% along each axis). The gaze point is whatever you set with the pointer, keys or sliders.
- How outputs are derived
- Inside the foveal radius a tile keeps full detail. Beyond it, detail falls from 100% to the peripheral quality over a distance set by softness, using a smooth curve, then snaps to the nearest of the eight levels. Workload = sum of
tile area × level²divided by the total area, because shaded pixels scale with the square of linear resolution. - What you can conclude
- Why concentrating detail can cut shading work a lot, and why fixed foveation fails when your eyes leave the center.
- What it does not tell you
- Real frame-time savings. Those depend on implementation (for example variable-rate shading or multi-resolution rendering), hardware, shading cost, resolution, eye-tracking latency and accuracy, and how much quality loss is acceptable. Lowering the quality of a finished image is not how a real eye-tracked pipeline works, and the workload figure ignores geometry and fixed per-frame costs.
Display Persistence & Motion Clarity
Understand
On a sample-and-hold display each frame stays lit for most of the refresh interval. When your eyes follow a moving object, the picture holds still while your eye keeps moving, so every frame smears across your retina. Lighting each frame for less time, which is lower persistence, shrinks the smear.
SIMULATION — NOT A HARDWARE MEASUREMENTSimulated: an illustrative smear computed from speed and persistence. It is not a calibrated optical model of any headset.
Experiment
How long each frame is lit. It cannot exceed the refresh interval.
The smear in the diagram is scaled so each frame step is easy to see. The numbers below use the actual speed and persistence you set.
- Refresh interval
- Effective persistence
- Share of each frame that is lit
- Smear width on this canvas
- Object step per frame
Observe
Apply
When comparing headsets, look beyond refresh rate: how long each frame stays lit matters too. Shorter persistence makes moving objects crisper but usually costs brightness, and some implementations can show flicker, so it is a trade-off.
How this simulation works
- What is simulated
- An object moving at a constant speed while a perfectly tracking eye follows it, seen on a display that lights each frame for a set time.
- How outputs are derived
- Interval
T = 1000 / Hz. Effective persistenceP = min(setting, T). Smear width =speed × P, drawn by averaging the sprite over that distance. Step per frame =speed × T. The reference rows use no smear, 1 ms, your value, and a full-frame hold (P = T). - What you can conclude
- Smear grows with speed and with how long a frame is lit. Refresh rate matters because it caps the longest possible hold, but a low-persistence display at a modest refresh rate can look sharper than a full-hold display at a higher one.
- What it does not tell you
- How a particular headset looks. Real panels differ in pixel response, brightness, strobing, and eye-tracking accuracy. Persistence is not the same thing as latency, and it is not a total measure of motion quality.