Additional color format checks #1396
Conversation
Implemented a utility function to call the SupportsColorFormat check, with additional logging about the selected color format. Ensure that selected color format is supported by the runtime's swapchain.
We decide the layerCube's color format in BrowserWorld::CreateSkybox based on the extension of the images. In the case of ktx we assign to the The Finally, as part of the initialization of the cubeLayer, we use it create the XrSwapchainCreateInfo structure for the swapchain. |
Yeah I know the codepath, the thing is why would we ever pass an unsupported value? As you mentioned is something that we control in the code, not something that could depend on some variable. |
Well, we select the color format depending on the skybox's image file extension, which can be come externally via the remote environments. Also, this code is multi-platform, so it'd might hit in some devices but not in others. The alternative is to let the OpenXR calls to fail, but I think the error can be less clear and harder to figure out its root cause. |
|
We were in doubts to land this as the benefit is questionable. Let's close this now, we can always retake it in the future |
We already have a function to ensure that the XrSwapchainCreateInfo structure provides a compatible color format. We were using this check when creating the swapchains for the views, as part of the GetSwapChainCreateInfo() logic,
However, when we create the OpenXRLayerCube instance we pass a color format Id that is later used in the XrSwapchainCreateInfo structure during the layer initialization. This PR provides a more descriptive error and avoids the failure on the OpenXR code.