A-Frame tick() and the WebXR frame callback: which layer defines the frame budget?

Question

On an A-Frame 1.x scene, the goal before optimizing is to locate the actual frame bottleneck rather than guess. Two timing sources sit at the integration boundary: the stats component, which times the ECS tick() loop on the CPU, and the WebXR session's frame callback, which delivers an XRFrame timestamp tied to the compositor's schedule.

The two loops are not guaranteed to stay in lockstep. A-Frame drives rendering through the browser's animation loop, while an immersive session schedules frames via XRSession.requestAnimationFrame; implementations differ in how the callbacks interleave, so timing taken around tick() may drift from compositor timing by up to a frame. The stats readout also covers JavaScript execution only; GPU work and compositor overhead stay invisible, which matters for shader-heavy or draw-call-heavy scenes. Behavior varies across desktop Chrome and standalone headset browsers, so version and hardware assumptions should be pinned before comparing numbers.

That leaves an unresolved instrumentation decision:

Should the frame budget be measured at the tick() level, at the XRFrame callback level, or correlated across both?
Can drift between the two loops be bounded reliably on the target browsers, or does it need per-session calibration?
Do GPU-bound stalls surface at either measurement point, or does isolating them require a separate GPU profile?

Tasadduq Burney · Answer

Answer
The authoritative frame budget comes from the XRSession.requestAnimationFrame callback – the XR runtime’s compositor schedule. A‑Frame’s tick() loop only measures JavaScript/ECS work on the CPU; it does not include GPU rendering, draw submission, or compositor overhead.
Why that matters

In an immersive session the display refresh (e.g., 72 Hz, 90 Hz) is enforced by the XR runtime. The XRFrame timestamp is the moment the runtime expects your frame to be ready for presentation.
A‑Frame drives tick() via the browser’s requestAnimationFrame loop. The two loops can drift by up to one frame depending on the browser and device, so a fast tick() does not guarantee a frame is delivered on time.
GPU‑bound stalls only surface as missed or elongated XRFrame intervals; they are invisible to tick() timing alone.

How to find the real bottleneck

Log both timestamps. In an A‑Frame component, capture performance.now() before and after the tick() call, and inside session.requestAnimationFrame log the XRFrame timestamp and the delta to the previous frame.
Correlate the data. A long tick() that aligns with an elongated XRFrame interval indicates a CPU‑side bottleneck. A short tick() paired with a long XRFrame gap points to GPU or compositor stalls.
Use a GPU profiler. If you suspect GPU contention, run the browser’s trace (e.g., Chrome DevTools → Performance → “Record GPU timeline”) or the headset vendor’s profiling tool. Look for long draw calls or missed frame deadlines.
Repeat per target. Browser and headset implementations differ, so perform the measurement on each target device to bound the tick()‑to‑XRFrame drift empirically.

Practical takeaway
Measure the XRFrame timestamps to establish the frame budget, and use tick() timing only as a CPU cost proxy. Correlating the two gives a clear picture of where the scene is spending time.
What’s still uncertain?
Because the drift between tick() and XRFrame is implementation‑dependent, a per‑session calibration is the safest approach. If you’re targeting a specific browser or headset, let us know so we can fine‑tune the recommendation.

A-Frame tick() and the WebXR frame callback: which layer defines the frame budget?

1 answer

Answer

Why that matters

How to find the real bottleneck

Practical takeaway

What’s still uncertain?

Your perspective belongs here.

0 question comments