We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
I notice some more suspicious swapchain RFC keyword usage:
The possible return values for vkGetSwapchainStatusKHR should be interpreted as follows:
vkGetSwapchainStatusKHR
The "should" feels odd here and colloquial. Should be refrazed in the form of what the implementation must return.
If a counter is not available because the swapchain is out of date, the implementation may return VK_ERROR_OUT_OF_DATE_KHR.
VK_ERROR_OUT_OF_DATE_KHR
"may" feels suspicious here. Posibly supposed to be "must".
As usual, vkQueuePresentKHR may fail if oldSwapchain has entered a state that causes VK_ERROR_OUT_OF_DATE_KHR to be returned.
vkQueuePresentKHR
oldSwapchain
The "may" is weird, because tautologically if VK_ERROR_OUT_OF_DATE_KHR is returned, then it did fail.
The text was updated successfully, but these errors were encountered:
Recommendation:
This text is directed to application not implementation. Change "should be interpreted as follows" to " indicates the following"
"may" change to "must"
Sorry, something went wrong.
stonesthrow
Successfully merging a pull request may close this issue.
I notice some more suspicious swapchain RFC keyword usage:
The "should" feels odd here and colloquial. Should be refrazed in the form of what the implementation must return.
"may" feels suspicious here. Posibly supposed to be "must".
The "may" is weird, because tautologically if
VK_ERROR_OUT_OF_DATE_KHR
is returned, then it did fail.The text was updated successfully, but these errors were encountered: