Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
S-Dafarra opened this issue Jul 2, 2021 · 6 comments
Labels
synced to gitlab A corresponding issue has been filed in the Khronos internal GitLab

Comments

@S-Dafarra
Copy link

S-Dafarra commented Jul 2, 2021

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
Copy link
Collaborator

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.

@rpavlik-bot rpavlik-bot added the synced to gitlab A corresponding issue has been filed in the Khronos internal GitLab label Jul 14, 2021
@brycehutchings
Copy link

brycehutchings commented Jul 22, 2021

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
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link
Contributor

rpavlik commented Aug 24, 2021

Fix released in OpenXR 1.0.19 - thanks for the report!

@rpavlik rpavlik closed this as completed Aug 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
synced to gitlab A corresponding issue has been filed in the Khronos internal GitLab
Projects
None yet
Development

No branches or pull requests

4 participants