OpenXR 超详细spec--Chapter 2 基本原理

2.5. Runtime

An OpenXR runtime是实现OpenXR API的软件。一个系统中可能安装不止一个openXR runtime，但是在任何时间只有一个runtime是active。

2.6. Extensions

OpenXR是一个可扩展的API，可以通过添加new features进行扩展。和其他Khronos APIs类似，extension可以用来expose new OpenXR functions or modify 现有的openXR functions的功能。 Extensions是可选的，因此必须在扩展功能可用之前先由application使能它。因为Extensions是可选的，他们只能在runtime、graphics platforms、OS的子集上实现。因此，application必须先查询哪些extensions是可用的，然后再enable extensions。 Application使用xrEnumerateInstanceExtensionProperties()查询可用的extensions list。一旦application确定了支持哪些extension，它可以在调用xrCreateInstance()期间启用extensions的某些子集。 OpenXR Extenstions具有唯一的name，该name可以传达所提供功能的信息。

格式如下：

• “XR_” 前缀来标识它是一个openXR extension。
• Vendor tag的字符串标识也是扩展，tag必须是大写字母和十进制数字。
• KHR：是Khronos extension。
•  “EXT”：是非Khronos extension。
• “_”下划线 唯一标识扩展的字符串，它只能使用小写字母和十进制数字，子串之间用“_”连接。 Eg：XR_KHR_composition_layer_cube

2.7 API Layers

OpenXR是一个分层的API，意味着用户或application可以在application和runtime实现之间插入API layers。这些API layers能够提供额外的功能，他们通过从上层拦截OpenXR功能来执行不同的操作，这个不同的操作是和没有该layer的对比。 在最简单的情况下，the layer仅仅使用相同参数向下调用下一层，但是一个更复杂的layer可能会实现它下层或者runtime中不存在的API功能。这种机制本质上是一种架构的“function shimming函数填充”或者“intercept拦截”feature，这种架构被设计到openXR中，mean to replace more informal methods of "hooking" API calls.

2.8. Return Codes

虽然核心API没设计去捕获不正确的使用，但一些情况仍需要return codes。API中的函数通过return code返回他们的状态。

Return code有两类：

• Suceessful completion codes：非负值
• Runtime error code：负值。

typedef enum XrResult {
    XR_SUCCESS = 0,
    XR_TIMEOUT_EXPIRED = 1,
    XR_ERROR_VALIDATION_FAILURE = -1,
    XR_ERROR_RUNTIME_FAILURE = -2,
}

2.9. Handles

2.10. Object Handle Types