search

KhronosGroup / OpenXR-Docs

OpenXR Specification sources and related material
Other
143 stars 62 forks source link

Clarify the point with respect to which an offset is defined in an imageRect #86

Closed S-Dafarra closed 3 years ago

S-Dafarra commented 3 years ago

For example, in Section 10.4.5

imageRect is an XrRect2Di representing the valid portion of the image to use, in pixels. It also implicitly defines the transform from normalized image coordinates into pixel coordinates. Note that the compositor may bleed in pixels from outside the bounds in some cases, for instance due to mipmapping.

and then XrRect2Di is defined in 2.17

offset is the XrOffset2Di specifying the integer rectangle offset. extent is the XrExtent2Di specifying the integer rectangle extent.

Although, it is not clear to me with respect to which point of the full swapchain image the offset is defined. Is it the top left corner, or the bottom left as for OpenGL textures?

rpavlik-bot commented 3 years ago

An issue (number 1587) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#1587 ), to facilitate working group processes.

This GitHub issue will continue to be the main site of discussion.

brycehutchings commented 3 years ago

It depends on the graphics API being used. For OpenGL/GLES the spec says:

The OpenXR runtime must interpret the bottom-left corner of the swapchain image as the coordinate origin unless specified otherwise by extension functionality.

For D3D/Vulkan the spec says:

The OpenXR runtime must interpret the top-left corner of the swapchain image as the coordinate origin unless specified otherwise by extension functionality.

S-Dafarra commented 3 years ago

Clear thanks, I did not notice those lines at first. Would it make sense to mention earlier on the spec that its definition depends on the graphics API?

Also, I wonder if this may cause a different behavior when using different runtimes. For example, I recently had a problem with the visualization of a XrCompositionLayerQuad when using a swapchain size bigger than the image to display. I developed an app in Linux exploiting the monado runtime, using the imageRect to visualize only the portion of the swapchain image I was interested in. When testing the same app with the SteamVR runtime on Windows, I was not able to visualize anything anymore. This got fixed when I started using the entire swapchain image (i.e. setting the offset to zero and setting the extent equal to the swapchain size). I suspect this was because the runtime was visualizing the wrong portion of the swapchain image., but I am just guessing.

brycehutchings commented 3 years ago

Would it make sense to mention earlier on the spec that its definition depends on the graphics API?

Yes, agreed. I am making an update to the spec to clarify this on the imageRect definition.

I'll bring your compatibility problem up with the appropriate people to see if they might know what is going.

S-Dafarra commented 3 years ago

Would it make sense to mention earlier on the spec that its definition depends on the graphics API?

Yes, agreed. I am making an update to the spec to clarify this on the imageRect definition.

I'll bring your compatibility problem up with the appropriate people to see if they might know what is going.

Thanks a lot, I appreciate!

rpavlik commented 3 years ago

Fix released in OpenXR 1.0.19 - thanks for the report!