XrOffset2Df - Float offset in two dimensions

Member Descriptions

Description

This structure is used for component values that may be fractional (floating-point). If used to represent physical distances, values must be in meters.

See Also

Extent2Df, Rect2Df

XrExtent2Df - Extent in two dimensions

Member Descriptions

Description

This structure is used for component values that may be fractional (floating-point). If used to represent physical distances, values must be in meters.

The width and height value must be non-negative.

See Also

CompositionLayerQuad, Offset2Df, Rect2Df, getReferenceSpaceBoundsRect

XrRect2Df - Rect in two dimensions

Member Descriptions

Description

This structure is used for component values that may be fractional (floating-point).

See Also

Extent2Df, Offset2Df

XrOffset2Di - Offset in two dimensions

Member Descriptions

Description

This variant is for representing discrete values such as texels. For representing physical distances, the floating-point variant must be used instead.

See Also

Extent2Di, Rect2Di

XrExtent2Di - Extent in two dimensions

Member Descriptions

Description

This variant is for representing discrete values such as texels. For representing physical distances, the floating-point variant must be used instead.

The width and height value must be non-negative.

See Also

Offset2Di, Rect2Di

XrRect2Di - Rect in two dimensions

Member Descriptions

Description

This variant is for representing discrete values such as texels. For representing physical distances, the floating-point variant must be used instead.

See Also

Extent2Di, Offset2Di, SwapchainSubImage

XrBool32 - Boolean value

Description

Boolean values used by OpenXR are of type https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrBool32 and are 32-bits wide as suggested by the name. The only valid values are the following:

Enumerant Descriptions

See Also

ActionStateBoolean, ActionStateFloat, ActionStatePose, ActionStateVector2f, EventDataMainSessionVisibilityChangedEXTX, EventDataReferenceSpaceChangePending, FrameState, HandJointLocationsEXT, HandMeshMSFT, SecondaryViewConfigurationStateMSFT, SystemEyeGazeInteractionPropertiesEXT, SystemHandTrackingMeshPropertiesMSFT, SystemHandTrackingPropertiesEXT, SystemTrackingProperties, ViewConfigurationProperties, xrSetInputDeviceActiveEXT, xrSetInputDeviceStateBoolEXT

XrFlags64 - OpenXR bitmasks

Description

Bitmasks are passed to many functions and structures to compactly represent options and are stored in memory defined by the https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrFlags64 type. But the API does not use the https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrFlags64 type directly. Instead, a Xr*Flags type is used which is an alias of the https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrFlags64 type. The API also defines a set of constant bit definitions used to set the bitmasks.

See Also

CompositionLayerFlags, InstanceCreateFlags, SessionCreateFlags, SpaceLocationFlags, SwapchainCreateFlags, SwapchainUsageFlags, ViewStateFlags

XrTime - Basic type for time

Description

https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#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. https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#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 https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#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 https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrTime, and related functions must return error ERROR_TIME_INVALID. Applications must not initialize such https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrTime fields to a zero value. Instead, applications should always assign https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#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 https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#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 https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#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.

See Also

ActionStateBoolean, ActionStateFloat, ActionStateVector2f, https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrDuration, EventDataInstanceLossPending, EventDataReferenceSpaceChangePending, EventDataSessionStateChanged, EyeGazeSampleTimeEXT, FrameEndInfo, FrameState, HandJointsLocateInfoEXT, HandMeshUpdateInfoMSFT, HandMeshVertexBufferMSFT, SpatialAnchorCreateInfoMSFT, ViewLocateInfo, convertTimeToTimespecTimeKHR, convertTimeToWin32PerformanceCounterKHR, convertTimespecTimeToTimeKHR, convertWin32PerformanceCounterToTimeKHR, locateSpace

XrDuration - Bounded range of time

Description

The difference between two timepoints is a duration, and thus the difference between two https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrTime values is an https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrDuration value.

Functions that refer to durations use https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrDuration as opposed to https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrTime.

See Also

FrameState, HapticVibration, SwapchainImageWaitInfo, https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrTime