typedef int64_t XrTime;
XrTime is a base value type that represents time as a signed 64-bit integer, representing the monotonically-increasing count of nanoseconds that have elapsed since a runtime-chosen epoch. XrTime always represents the time elasped since that constant epoch, rather than a duration or a time point relative to some moving epoch such as vsync time, etc. Durations are instead represented by XrDuration.
A single runtime must use the same epoch for all simultaneous applications. Time must be represented the same regardless of multiple processors or threads present in the system.
The period precision of time reported by the runtime is runtime-dependent, and may change. One nanosecond is the finest possible period precision. A runtime may, for example, report time progression with only microsecond-level granularity.
Time must not be assumed to correspond to a system clock time.
Unless specified otherwise, zero or a negative value is not a valid
XrTime, and related functions must return error
Applications must not initialize such XrTime fields to a zero
Instead, applications should always assign XrTime fields to the
meaningful point in time they are choosing to reason about, such as a
frame’s predicted display time, or an action’s last change time.
The behavior of a runtime is undefined when time overflows beyond the maximum positive value that can be represented by an XrTime. Runtimes should choose an epoch that minimizes the chance of overflow. Runtimes should also choose an epoch that minimizes the chance of underflow below 0 for applications performing a reasonable amount of historical pose lookback. For example, if the runtime chooses an epoch relative to its startup time, it should push the epoch into the past by enough time to avoid applications performing reasonable pose lookback from reaching a negative XrTime value.
An application cannot assume that the system’s clock and the runtime’s clock will maintain a constant relationship across frames and should avoid storing such an offset, as this may cause time drift. Applications should instead always use time interop functions to convert a relevant time point across the system’s clock and the runtime’s clock using extensions, for example, https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XR_KHR_win32_convert_performance_counter_time or https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XR_KHR_convert_timespec_time.
XrActionStateBoolean, XrActionStateFloat, XrActionStateVector2f, XrDuration, XrEventDataInstanceLossPending, XrEventDataMarkerTrackingUpdateVARJO, XrEventDataReferenceSpaceChangePending, XrEventDataSessionStateChanged, XrEyeGazeSampleTimeEXT, XrFacialExpressionsHTC, XrFrameEndInfo, XrFrameState, XrGeometryInstanceTransformFB, XrHandJointsLocateInfoEXT, XrHandMeshUpdateInfoMSFT, XrHandMeshVertexBufferMSFT, XrSceneBoundsMSFT, XrSceneComponentMSFT, XrSceneComponentsLocateInfoMSFT, XrSpatialAnchorCreateInfoFB, XrSpatialAnchorCreateInfoMSFT, XrSpatialGraphStaticNodeBindingCreateInfoMSFT, XrViewLocateInfo, xrConvertTimeToTimespecTimeKHR, xrConvertTimeToWin32PerformanceCounterKHR, xrConvertTimespecTimeToTimeKHR, xrConvertWin32PerformanceCounterToTimeKHR, xrLocateSpace
For more information, see the OpenXR Specification
This page is extracted from the OpenXR Specification. Fixes and changes should be made to the Specification, not directly.
Copyright 2014-2022 The Khronos Group Inc.
This work is licensed under a Creative Commons Attribution 4.0 International License.