How does foveated rendering work, what does it need to be safe, and what does it genuinely buy you?

Short answer

Human acuity collapses away from the fovea, so a renderer can shade the periphery at a fraction of the centre's sample rate without a visible difference. Gaze-tracked variants follow the eye and save more; both save only pixel-shading work, so a CPU-bound or vertex-bound application gains nothing at all.

What it exploits

Your retina is not uniform. Cone density peaks in a very small central region, the fovea, covering only about the central couple of degrees of your visual field, and visual acuity falls off steeply with angular distance from it. Everything you feel you can see sharply, you are seeing sharply because your eyes move constantly to put it on the fovea. Peripheral vision is excellent at detecting motion and change and poor at resolving detail.

A headset renders a wide field of view at a uniform sample rate, which means it spends the same effort per pixel on the region your fovea is examining and on the region where you could not resolve that detail if you tried. Foveated rendering is the correction: shade a small central region at full rate and reduce the sample rate progressively outwards.

The saving is arithmetic once you fix the sample rates. If a peripheral region is shaded once per 2x2 block of pixels, you run a quarter of the fragment-shader invocations over that region; once per 4x4 block, a sixteenth. Because the periphery is by far the larger share of the image area, even modest reductions cover a lot of pixels. Take a simple worked case with a stated premise: suppose the full-rate foveal region covers a fifth of the frame's area and the remaining four-fifths is shaded at quarter rate.

The shading work becomes 0.2 plus 0.8/4, which is 0.4 of the original — a 60% reduction in fragment work for that frame. Real numbers depend entirely on the falloff curve you choose, but the shape of the win is that.

Fixed versus gaze-tracked

The version that needs no eye tracking is fixed foveation: keep the centre of each eye's rendered image at full rate and drop the rate towards its edges. It is defensible without knowing where the user is looking because the optics themselves are not uniform — the lens resolves the centre of the display best, and the extreme edges of the rendered image are compressed and distorted by the barrel distortion the runtime applies. Fixed foveation is safe, always available, and conservative, because it must assume the user might look anywhere within the region it keeps sharp.

Gaze-tracked foveation moves the high-rate region to wherever the eye is actually pointing. That allows a much smaller sharp region and therefore a much larger saving, and it converts the technique from a modest optimisation into a significant one. It also introduces a dependency on hardware that can fail.

flowchart TD
  A[Eye tracker<br/>reports gaze] --> B{Confidence<br/>acceptable?}
  B -->|Yes| C[Move high-rate region<br/>to gaze point]
  B -->|No| D[Fall back to<br/>fixed foveation]
  C --> E[Shading-rate map<br/>for this frame]
  D --> E
  E --> F[Rasterise and shade<br/>at varying rates]
  F --> G[Distortion and present]

Note where the fallback rejoins: the renderer never has a state in which it has no shading-rate map, so a tracker that drops out degrades the saving rather than the frame.

The timing requirement on gaze

Eyes move in saccades that are extremely fast, and they can begin without warning. If your high-rate region arrives where the eye already was rather than where it is, the user momentarily fixates on undersampled pixels and sees the artefact directly, usually as a shimmer or a softness that resolves a moment later. The gaze sample therefore has to be consumed as late as possible in the frame, on the same principle as late-latching the head pose, and the whole chain from sensor to shading-rate map must complete inside the frame. At 90Hz that is a budget of about 11ms end to end; being one frame stale already means the region is roughly 11ms behind the eye.

This is also why the falloff must be gradual rather than a hard step. A sharp boundary between full rate and quarter rate is visible as an edge whenever the gaze estimate is slightly off, whereas a gradient tolerates a small error invisibly.

Where the saving does not appear

The claim to interrogate is what part of the pipeline foveation actually touches. It reduces fragment-shading work: the per-pixel cost of lighting, texturing and post-processing. It does not reduce the number of draw calls you issue, the number of vertices you transform, the CPU cost of your scene traversal and culling, your physics, or your animation. It does not reduce the memory bandwidth spent on geometry, and depending on the implementation it may not reduce depth-buffer or stencil work much either.

The consequence is blunt and it is the thing weaker answers miss: if your application is CPU-bound, foveated rendering buys you approximately nothing, and turning it on will produce a measurement that looks like it did nothing because it did. The correct order is to determine whether you are CPU-bound or GPU-bound first, and then whether the GPU time is going to fragments or to vertices and geometry, and only then reach for foveation. A candidate who profiles before optimising has answered the question the interviewer was really asking.

The costs beyond the artefacts

Eye tracking has to be calibrated, and calibration quality varies with how the headset sits, with eye shape, with makeup, and with glasses. A user for whom tracking is poor gets either a conservatively large sharp region, which erases most of the benefit, or a badly placed one, which is worse than no foveation. So the system needs a confidence signal and a policy for low confidence, and the policy has to be graceful rather than a hard toggle that the user perceives as flicker.

Gaze is also unusually sensitive personal data. It reveals attention, and attention reveals interest, reading ability, fatigue and more. A design that ships gaze samples off-device for any purpose other than rendering is a privacy decision, not an engineering one, and raising that unprompted in an interview reads as maturity rather than as a digression.

Establish whether you are fragment-bound before you reach for foveation, because it is the only part of the frame the technique can make cheaper.

© 2026 Preptima. Originally published at preptima.com.