VRHow / XR Technology / Eye tracking and foveated rendering
Eye tracking and foveated rendering
Last checked October 11, 2026. This is an evidence-led explainer, not a hands-on device test. Availability and behaviour vary by headset, operating system, runtime, graphics API and permission settings.
What the two technologies actually do
Human vision is not equally sharp across the whole field of view. A headset can therefore render the centre at a high rate and reduce pixel density toward the edges. Unity's OpenXR documentation describes this as lowering resolution in peripheral areas, using variable shading rate techniques to reduce the amount of shading work.
Eye tracking is the sensing step: inward-facing cameras and illumination estimate eye pose or gaze direction. In OpenXR, the XR_EXT_eye_gaze_interaction extension exposes an eye-gaze pose to an application when the runtime supports it. That is a developer-facing interface, not a promise that every headset or every app exposes the data.
Foveated rendering is the rendering policy. It creates a high-detail region and lower-detail regions, usually by supplying a shading-rate or density map to the graphics pipeline. It is useful because the application can redirect saved GPU work toward higher resolution, more effects, higher frame rate or lower power use. Those are options, not guaranteed outcomes: the developer must measure the particular scene and decide where to spend the budget.
Fixed versus gaze-based foveation
| Mode | Where detail follows | What it means in practice |
|---|---|---|
| Fixed foveated rendering | A predetermined centre region | Works without eye tracking and can be simpler, but looking toward an edge can reveal reduced detail. |
| Dynamic / gaze-based foveation | Your estimated gaze point | Can place detail where you look, but depends on calibration, tracking quality, latency and runtime support. |
That distinction matters more than the marketing label “foveated.” Unity notes that fixed foveation can be more apparent when users move their eyes toward the periphery. Gaze-based rendering is not magic either: the high-detail area must move quickly and accurately enough that the lower-detail boundary is not distracting. A device may support eye tracking but not expose it to an app, or an app may fall back to fixed foveation when permission is denied or gaze support is unavailable.
What performance improvement should you expect?
There is no honest universal percentage. The saving depends on render resolution, foveation strength, shading complexity, anti-aliasing, post-processing, scene geometry, graphics API and the device's implementation. Meta's current Unity guide explicitly tells developers to profile different foveation levels and render-target sizes because GPU savings depend on application content. It also documents ETFR as a feature for Meta Quest Pro and Meta VR Glasses in that guide's stated software context—not as a general capability of every Quest headset.
For a player, the useful question is not “Does this headset have eye tracking?” but “What does the software do with the resulting headroom?” A game might preserve a stable frame rate in a dense scene, increase eye-texture size for a crisper image, or add effects. A lightweight app may show little visible difference. Foveation also cannot fix CPU bottlenecks, slow asset streaming, wireless latency or a poorly tuned application.
The costs and failure modes
- Calibration and fit matter. If the headset shifts, lenses are misaligned, or the user has difficulty calibrating, gaze placement can be less reliable. Glasses, eyelids and individual eye characteristics can affect results.
- Permission is part of the feature. On Android XR deployments, eye-tracking data requires permission. Unity documents a fallback to fixed foveation if permission is denied; Meta likewise says ETFR will not turn on when eye tracking is disabled or permission is declined.
- Artifacts are possible. Aggressive settings can make peripheral detail look soft, blocky or unstable. Rapid eye movements, tracking loss and a moving boundary are reasons to judge the whole experience, not a benchmark number.
- Eye data is sensitive. Gaze can reveal attention and behaviour. Before enabling it, check the platform's privacy explanation, app permission request and data policy. An app should not need to collect raw gaze remotely merely to use a local rendering optimization.
A practical evaluation checklist
When comparing a headset or an XR app, ask these questions:
- Is eye tracking present, and is it available in this region, OS version and connection mode (standalone versus PC streaming)?
- Does the software support gaze-based foveation, or only fixed foveation? What is the fallback when tracking or permission is unavailable?
- Can the user reduce or disable foveation? Look for a comfort or graphics setting rather than assuming the default is ideal.
- Was performance measured in the actual app and scene? Ask whether the stated gain is GPU frame time, total frame rate, power consumption or an internal test.
- What visual trade-off is being accepted? Test text, thin lines and objects at the edge of vision—not just a central menu.
- What data leaves the device? Distinguish a local gaze signal used by the renderer from storage, analytics or sharing of gaze information.
Bottom line: eye tracking is valuable when it enables a well-tuned gaze-based renderer, but it is not a stand-alone quality score. Treat foveation as a budget-management technique: judge the fallback, visual artefacts, permissions and measured result for the software you actually plan to use.
Sources and method
The links below were opened and checked for the claims above. Vendor documentation describes supported implementations and may be version-specific; it is not independent proof of a particular performance gain. VRHow has not independently tested the devices or reproduced the vendor benchmarks.
- Unity OpenXR: Foveated rendering — fixed/gaze-based behaviour, variable shading rate, permissions and fallback.
- Meta Horizon OS Developers: Eye Tracked Foveated Rendering — current Meta Unity prerequisites, permission behaviour and profiling guidance (updated October 7, 2026).
- Khronos OpenXR specification: XR_EXT_eye_gaze_interaction — standard eye-gaze interaction data model and validity flags.
- Tobii: Eye tracking and dynamic foveated rendering — supplier explanation of the system-level trade-off and potential uses of freed resources.