The Gold Standard of Virtual Reality | Separating Pose Sample Age from Rendering Time

A timing question needs a start event, an end event and a relationship between them. GPU execution duration starts when specified graphics work begins and ends when it completes under the measurement definition. Sample age starts at the selected information’s source time and ends at the presentation event being examined.

A motion-to-photon measurement has its own defined physical motion and visible-response endpoints. Application logs alone may not observe both of those physical events. A number called latency is incomplete until the record explains which events it actually spans.

Imagine a fictional dashboard with three figures: eight milliseconds of GPU work, a ten-millisecond presentation interval and twenty milliseconds from a selected sample to display. All three can be correct because they describe different intervals. There is no need to choose one as the true number and dismiss the others.

For a first exercise, replace each label with a sentence. “The GPU work for this image ran from this timestamp to that timestamp.” “The view used this source sample and was presented at that time.” The sentences reveal missing endpoints more clearly than a row of impressive performance values.

This is the first-principles step. Before optimising, diagnosing or comparing systems, establish what was measured. A shorter interval is useful only in relation to the task it describes, and an undefined interval cannot establish that the complete movement-to-display pathway has become faster.

Contents · Next chapter

Let s be the capture time of a selected sample in our single-source toy model. Let l be the time the application looks up or receives the information. Let p be the target time for which a predicted pose is requested. Let d be the actual presentation time used in the teaching record.

These times need not be equal. A sample can be captured before the application asks for it. A prediction can describe a time after the lookup. Actual presentation can differ from the target. Each difference answers a separate question.

For unpredicted information, d − s is its source age at display. The delivery interval l − s describes how old it already was when obtained. The remaining interval d − l describes how much later it was presented. When all timestamps share a valid clock mapping, those two intervals add to d − s.

The target difference p − s is a prediction horizon in a deliberately specified single-source model. The actual mismatch d − p tells us whether the image was presented at the time for which that estimate was intended. Neither expression automatically measures prediction error in position or orientation.

Real estimators can combine many measurements over time, so one capture timestamp may not describe all their evidence. Our simple s makes the accounting visible. Do not assume an actual pose API exposes exactly that field or that one scalar age summarises every component of a fused estimate.

Contents · Previous chapter · Next chapter

Subtracting timestamps is meaningful only when their scales and origins are compatible. A tracking device may count time from one origin while a host process uses another. Two values both labelled milliseconds can still belong to different clocks.

Suppose a fictional tracker clock reads 1,050 ms at capture, and the host records presentation at 60 ms. Direct subtraction gives −990 ms. That does not demonstrate a display showing the future. The supplied clock relationship is host time = tracker time − 1,000 ms, so capture occurred at host time 50 ms and the age is ten milliseconds.

A constant offset is the simplest teaching conversion. If clocks also run at slightly different rates, the mapping can require a scale factor as well: host time = a × tracker time + b. The evidence for that mapping and its uncertainty belongs in the timing account.

Do not infer synchronisation from matching units, a shared file or similar-looking numbers. A timestamp copied into another system retains its clock meaning unless an appropriate conversion has been applied. Equally, do not confuse a negative age caused by mismatched clocks with one caused by subtracting a future prediction target from an earlier event.

A good record card identifies the clock for every field before calculating intervals. That makes later checks possible without inventing a correction after a surprising number appears. The lesson is about interpreting stipulated records, not a prescription for calibrating a real device’s clocks.

Contents · Previous chapter · Next chapter

Use one common clock and the following invented record. A sample is captured at 0 ms. The application obtains it at 2 ms. CPU work runs from 2 to 7 ms. GPU work runs from 5 to 13 ms. Submission is complete at 14 ms, and the selected presentation event occurs at 20 ms.

CPU duration is five milliseconds. GPU duration is eight. The source age at presentation is twenty. The sample was already two milliseconds old at lookup, and eighteen more milliseconds passed before presentation. Those intervals fit together without making either execution duration equal to the source age.

The table includes actual presentation as an explicit teaching input. It does not claim that a standard application timestamp directly measures emitted light. In a real investigation, the provenance of that endpoint must be established.

Check the order of the events, then compute the requested interval. A dashboard can report the correct eight-millisecond GPU duration while leaving sample age unreported. The missing information is not another decimal place in the GPU measurement. It is the relevant source and presentation relationship.

Contents · Previous chapter · Next chapter

In the fictional frame, CPU work occupies 2–7 ms and GPU work 5–13 ms. Their durations sum to thirteen milliseconds, but they overlap from five to seven. The elapsed span from CPU start to GPU completion is eleven milliseconds.

The sum of durations describes the amount of work across the two specified resources, under those definitions. It is not automatically a consecutive elapsed delay. Treating the resources as serial adds an overlap interval twice.

This does not mean that the total source age is eleven milliseconds either. The selected sample was captured at zero, and presentation occurs at twenty. The pre-work age, submission and presentation relationship remain outside that span.

A useful drawing uses parallel timeline rows for the CPU, GPU and presentation events. It helps a learner identify which intervals overlap without turning the diagram into a claim that every implementation has this schedule. Some work has dependencies, some can overlap and some can be queued elsewhere. The actual record determines the structure.

The official Unity 6 frame-timing documentation provides an engine-specific route into frame scheduling. Use the relevant software version for implementation details. Our numbers are independent exercises. The transferable habit is to distinguish duration on a resource, elapsed span across a dependency path and information age at the selected output event.

Contents · Previous chapter · Next chapter

Consider two images whose GPU work both runs from 5 to 13 ms and which are both presented at 20 ms. In record A, the selected unpredicted source sample was captured at zero. In record B, it was captured at minus eight milliseconds.

Their GPU durations are identical at eight milliseconds. Their source ages are twenty and twenty-eight milliseconds. Nothing in the GPU duration distinguishes them because the difference occurred before the work began.

This is a constructive counterexample to the claim that render time determines information age. The two records can share the execution interval and final presentation event while differing in the information they used. A queue, cache or delayed source could create such a distinction in a model; identifying the actual cause requires more evidence than the table supplies.

Now keep the sample fixed at zero but present the same completed image at thirty rather than twenty milliseconds. Its age becomes thirty. Again, the GPU duration has not changed. Waiting after completion can matter just as waiting before lookup can matter.

A useful review therefore follows the information from its source through the defined output event, instead of measuring only the busiest-looking processing stage. The longest computation can be important, but a short computation is not evidence that every other part of the timeline was short. Preserve the source identity and the actual frame relationship in the record.

Contents · Previous chapter · Next chapter

Define a simplified presentation model with events at 20, 30, 40 ms and so on. An image must be ready by 18 ms to use the 20 ms event, by 28 ms to use the 30 ms event, and similarly thereafter. These are stipulated classroom rules, not a runtime’s actual deadlines.

For a source sample captured at 8 ms, an image ready at 17.9 ms reaches the 20 ms event and has source age twelve milliseconds. If it is ready at 18.1 ms, it misses that event and reaches 30 ms, making the age twenty-two milliseconds.

A 0.2 ms readiness difference has created a ten-millisecond presentation difference in this model. The relationship is not a smooth one-to-one increase. It depends on which side of the deadline the result falls.

This explains why a small average rendering improvement may have little effect when no deadline changes, while a targeted improvement near a deadline can change the selected presentation slot. It does not establish how an actual system handles late frames, reprojection or scheduling.

When evaluating a timing claim, ask whether the comparison retained the presentation rule and whether the affected frames crossed a meaningful boundary. A lower mean execution time alone cannot answer that. The record needs enough detail to connect the changed work to the event at which the information was actually used.

Contents · Previous chapter · Next chapter

A display can present something every ten milliseconds while reusing information that is much older. Cadence describes how frequently presentation events occur. Freshness describes the age or validity of the state used at those events. They are related system concerns but not synonyms.

For a simple record, suppose presentations at 20, 30 and 40 ms all use a source state captured at zero. The cadence stays ten milliseconds, while source ages grow from twenty to thirty to forty. Counting three presentations does not show three new source measurements.

Alternatively, each presentation could use a newly generated image based on an old simulation state. The image identifier changes, but the relevant state age does not necessarily become small. A frame count describes events in one part of the system, not every input’s history.

The Virtual Reality root already distinguishes refresh interval from the whole response pathway. This example adds the record-level test: which source state did each displayed output actually represent?

Do not infer a capture timestamp solely from a sequence number. Counters can identify ordering within a specified stream without proving the elapsed time between samples. The existing Wearable Technology sample-counter guide develops that separate evidence problem. Use it when a timing claim begins with counts rather than actual, interpretable timestamps.

Contents · Previous chapter · Next chapter

Suppose a fictional estimator uses information captured at zero and, when called at 2 ms, returns a pose predicted for 20 ms. The target timestamp describes the state being predicted. It does not mean that physical measurements were captured at 20 ms during a call made eighteen milliseconds earlier.

This distinction matters in actual interfaces. The official OpenXR rendering specification source describes predicted display timing and view poses requested for a display time. It also states that predictions for the same target can be updated as the query approaches that time.

The application call time, target time and underlying measurement history are therefore different concepts. A future target does not make a pose’s supporting evidence newly captured, and it does not by itself establish the prediction’s error.

In our simple model, the prediction horizon from the selected sample is twenty milliseconds. If display occurs at the intended 20 ms, the target mismatch is zero. Yet a prediction could still be wrong because motion changed in a way the model did not predict.

A responsible report names the time a pose is intended to represent and, where available and meaningful, how its supporting information was obtained. It should not rename every target timestamp capture time merely because subtracting it produces an attractive small age.

Contents · Previous chapter · Next chapter

Assume a purely one-dimensional angular teaching model: orientation changes at a constant ninety degrees per second. Over twenty milliseconds, the angle changes by 90 × 0.020 = 1.8 degrees.

If an unpredicted orientation from time zero is displayed at 20 ms, its difference from the model’s current orientation is 1.8 degrees. If an exact constant-velocity predictor uses the same source information and predicts for 20 ms, its orientation error at that target is zero under the stipulated model.

The supporting sample is still twenty milliseconds old at presentation. Prediction did not change its capture time. It used a model to estimate a later state. Thus information age and prediction error can move differently.

Now let actual angular acceleration be six hundred degrees per second squared while the predictor keeps only the initial velocity. Over a horizon h, the omitted angular contribution is one-half times acceleration times h². At h = 0.020 seconds, that is 0.12 degrees; at 0.040 seconds, it is 0.48 degrees.

These are exact results for the supplied simplified motion, not typical human movement, comfort limits or performance requirements. They illustrate why a longer prediction horizon can increase sensitivity to a missing part of the motion model. A future timestamp is a statement of intended time, not a certificate of accurate prediction at that time.

Contents · Previous chapter · Next chapter

Keep the constant ninety-degree-per-second model. Suppose the image uses a pose predicted for 20 ms but is actually presented at 30 ms. The target mismatch is ten milliseconds. The orientation changes by another 0.9 degrees during that gap.

Even a perfect prediction for the original target is now a prediction for the wrong presentation time. Its error at 30 ms follows from the mismatch under this motion model. That is a different cause from incorrectly estimating the orientation at the intended 20 ms target.

This example connects deadline behaviour with prediction. If a frame moves to a later presentation event, the timing account should identify whether any relevant pose adjustment also occurred. Simply carrying the original future timestamp into the final report does not establish that it still matches display.

The OpenXR documentation’s target-time definitions help explain why a consistent display time matters across a frame’s stages. Our delayed-presentation example is a model for interpreting records, not a claim that a conforming runtime necessarily presents an unchanged frame in this way.

For an independent check, change the angular velocity to sixty degrees per second while retaining the ten-millisecond mismatch. The resulting model error is 0.6 degrees. The time mismatch has not changed, but its geometric consequence has. This is another reason a duration alone cannot establish a universal visual-error or experience-quality claim.

Contents · Previous chapter · Next chapter

A displayed image can depend on information from several times. Imagine a fictional pipeline whose scene geometry and animation state were prepared from time zero, but whose final view adjustment uses a pose estimate supported by a 16 ms sample before presentation at 20 ms.

Under this specified record, the supporting pose sample is four milliseconds old at presentation, while the scene state is twenty milliseconds old. Calling the whole image four milliseconds old would merge two different information paths. Calling every part twenty milliseconds old would miss the newer view adjustment.

This is why a single age label can be insufficient for a composite output. Viewpoint, object animation, input response and other scene changes can have different source histories. Their relationship matters to the question being investigated.

No general promise about a real reprojection technique follows from this model. Different methods preserve or approximate different relationships, and an image adjustment does not necessarily regenerate every scene property. The appropriate technical account belongs to the actual implementation and its documentation.

The learner’s task is narrower: draw the two information paths and label their source and presentation times. Then explain which claimed delay each path supports. This keeps a useful late update from being exaggerated into a statement that every part of the world representation was freshly recomputed. The same reasoning applies to other systems that combine new viewpoint information with older content.

Contents · Previous chapter · Next chapter

Suppose a fictional source captures samples every four milliseconds: 0, 4, 8, 12, 16, 20 and so on. The application looks up the latest available sample at 1, 11 and 21 ms. It therefore selects captures at 0, 8 and 20 ms.

The selected samples are one, three and one milliseconds old at lookup. If the corresponding presentations occur at 10, 20 and 30 ms, their source ages at presentation are ten, twelve and ten milliseconds. The processing pattern can remain otherwise unchanged while the source-to-lookup phase varies.

This variation is not necessarily an execution-time spike. It can arise from the relationship between two regular schedules. A plot that reports only GPU duration would not explain it because the changing interval occurred before that work.

An often-used simple phase model assumes a lookup falls uniformly within a sampling interval of length S. Under that assumption alone, the mean waiting age is S/2. That is a probability model, not a conclusion guaranteed by two periodic clocks. Locked phases or a deterministic schedule can give another distribution.

State whether a timing average came from observed records, a supplied probability model or a hypothetical worst-case range. Those are different kinds of evidence. The number of samples and the refresh cadence do not automatically specify the phase distribution needed to justify a particular mean source age.

Contents · Previous chapter · Next chapter

Consider fictional source ages of ten, ten, ten, ten and thirty milliseconds. Their mean is fourteen. Reporting only fourteen hides the one thirty-millisecond case, while reporting only thirty hides the typical values in this short record.

A useful description can include the individual values or a distribution summary, the observation period and the event definition. Five records are enough for an arithmetic lesson, not a dependable claim about long-run tail behaviour.

Now compare another record with fourteen milliseconds on all five occasions. It has the same mean and a different pattern. Which is preferable depends on the task and consequences being examined. The mean does not contain the entire temporal experience.

Keep the denominators consistent too. An average per generated frame differs from an average per displayed frame if some generated frames are not presented. An average per time interval can weight a long-held state differently from an unweighted list of state updates. The record needs to say what was counted.

This chapter is about interpretation rather than choosing a performance target. A meaningful comparison names the same endpoints, population and weighting before comparing summaries. Otherwise one system may appear faster simply because it reports a different subset of events. More decimal places do not resolve a denominator or sampling-boundary mismatch.

Contents · Previous chapter · Next chapter

Suppose a fictional capture event is known to lie between 3.5 and 4.5 ms on the common clock, while presentation lies between nineteen and twenty-one milliseconds. If every combination within those bounds is allowed, the age lies between 19 − 4.5 = 14.5 and 21 − 3.5 = 17.5 ms.

The central subtraction of twenty minus four gives sixteen. It is useful as a central arithmetic value, but it does not replace the supplied uncertainty bounds. If the clock conversion is uncertain too, that uncertainty must be represented appropriately rather than ignored.

Dependence can matter. Two timestamps derived from the same clock may share an offset that cancels in their difference. Timestamps converted from different clocks may retain a relative-offset uncertainty. The correct account follows the measurement model; it does not assume either complete cancellation or complete independence by convenience.

These are interval-bounds exercises. They do not assign probabilities to ages within the range. A standard uncertainty, confidence interval and hard timing bound are different objects, just as in other measurement problems.

The Uncertainty Quantification guide develops that broader distinction. Use it when a timing result’s uncertainty is being interpreted, while keeping the present guide’s event and clock definitions visible. A precise-looking difference between poorly defined timestamps is not automatically a precise physical measurement.

Contents · Previous chapter · Next chapter

A log may contain application lookup, submission and predicted display time without the capture time of supporting measurements or an observed presentation event. Such a record can support calculations among the fields it contains. It cannot, by itself, supply the missing physical endpoints.

For example, submission at fourteen and a target of twenty gives a six-millisecond target gap. Calling it measured submission-to-photon delay adds an observation that was not supplied. The target may be useful for scheduling while remaining a prediction.

Similarly, a pose returned at two milliseconds does not establish that its most recent contributing measurement was captured at two. Data delivery and data capture are different events. A fused estimator may not even have a single meaningful capture time for the whole output.

The practical repair is to write “not observed in this record” beside the missing endpoint. Then identify what evidence would be needed for the stronger claim. That is more informative than replacing the missing field with an assumed timestamp because the subtraction would otherwise be impossible.

This principle also protects the source documents. An interface can define a target time correctly without promising access to every hardware event required by a particular analysis. The limitation belongs to the proposed inference, not necessarily to the interface. Choose the question the available record can answer before demanding that a convenient log stand in for a complete physical experiment.

Contents · Previous chapter · Next chapter

A pose value can be meaningful for an application without representing a newly observed physical measurement. The official OpenXR spaces specification source distinguishes valid and tracked components and describes historical or predicted location queries.

Those distinctions should prevent a simple inference: a returned number is not automatically a current, directly measured position. A valid inferred or last-known component can serve a defined purpose while needing a different interpretation from actively tracked information.

Our timing table does not model all of these states. Its source-age subtraction assumes a specified sample relationship. Before applying that idea to actual records, the reader needs to know what the returned state represents and whether the required provenance is available.

A helpful fictional exercise supplies two pose records with identical coordinates but different status descriptions. One is actively tracked under the stipulated record; the other is an inferred continuation. The coordinates alone cannot tell the difference. The additional metadata change which claims about source evidence are justified.

This is another example of keeping a successful application output separate from the evidence behind it. A scene can continue to render while some tracking information has changed status. That observation should prompt the appropriate system investigation, not a diagnosis from visual smoothness or a claim that every coordinate has a fresh sensor observation behind it.

Contents · Previous chapter · Next chapter

Independent task A gives capture at five, lookup at eight, CPU work from eight to twelve, GPU work from ten to seventeen, submission at eighteen and presentation at twenty-five milliseconds. All times share the stipulated clock. Find GPU duration, CPU-to-GPU elapsed span and source age at presentation.

The answers are seven milliseconds, nine milliseconds and twenty milliseconds. CPU duration is four; adding four and seven gives eleven resource-milliseconds of work, not the nine-millisecond elapsed span because the work overlaps for two milliseconds.

Task B changes only the selected capture to minus five. The GPU duration and elapsed processing span stay unchanged; source age becomes thirty milliseconds. Explain why the workload record did not identify that difference.

Task C says the pose was predicted for thirty milliseconds during the lookup at eight. Can we call thirty its capture time? No. It is the supplied target time. If the presentation remains at twenty-five, the target mismatch is minus five milliseconds: the intended pose time is later than the selected display event.

Finally, remove the actual presentation observation and retain only a target. The record no longer supports an observed source-to-presentation age. State the missing event rather than silently promote the target into a measurement. A complete answer includes that stopping point as well as the intervals that remain calculable.

Contents · Previous chapter · Next chapter

A concise timing record can be more useful than a dashboard full of labels. Name the component or information path, the start and end events, clock mappings, frame identity and any target-time convention. Then state which intervals were observed and which were modelled or predicted.

The record should preserve limits. If only application timing is available, report application timing. If a prediction target is available, label it as such. If different state components have different histories, avoid a single age that conceals the distinction.

For a controlled change, ask what the change could affect in the model. Shortening GPU execution may alter readiness. A newer pose lookup may alter the information used. A clock correction may alter the interpretation of timestamps without changing physical behaviour. These are different mechanisms. A clear explanation connects the change with the interval it can legitimately influence before claiming an improvement to the whole experience.

Contents · Previous chapter · Next chapter

Does a high frame rate prove low source age?

No. Presentation cadence and source history are different. The repeated-state example presents regularly while its information grows older. Identify the state used at each output event.

Does prediction make old information new?

It estimates a later state from available evidence and a model. It can reduce error under suitable conditions without changing when its supporting measurements were captured. Model error and timing mismatch still matter.

Can CPU and GPU durations always be added?

Not as consecutive elapsed delay when their work overlaps. Inspect the intervals and dependency path. Resource work, elapsed span and source age answer different questions.

Is predictedDisplayTime an observed photon timestamp?

It is a predicted display-time field under the interface’s definition, not a substitute for independently establishing a physical presentation event for any desired measurement. Read the actual specification and measurement boundary.

Does this guide set acceptable VR latency or comfort limits?

No. It supplies fictional records for mathematical interpretation. Equipment suitability, individual needs and authorised use remain separate questions. None of the numerical examples is a universal target or product rating.

Contents · Previous chapter · Next chapter

For the experience and its learning purpose, return to Virtual Reality and Human–Computer Interaction. For measurement interpretation, use Measurement and Uncertainty Quantification.

For related source records, read Unwrapping Sample Counters Without Inventing Missing Time and Motion Capture, Sensors and the Measured Body. The first concerns counter evidence; the second connects movement measurement with interpretation. Neither replaces the timestamp relationships developed here.

Primary documentation reviewed on 22 October 2026 includes the OpenXR rendering chapter, OpenXR spaces chapter and Unity 6 VR frame-timing manual. Use current versions for implementation work. Our schedules, deadlines, motion models and numerical checks are original teaching assumptions, not descriptions of all runtimes.

Continue through Learning That Transfers into Life and How X Works. A useful finish is to explain one timeline without using the word latency until its endpoints are named. That habit keeps a fast-looking number connected to the actual question it can answer.

Contents · Previous chapter · Return to Virtual Reality