This repository has been archived by the owner on Oct 29, 2024. It is now read-only.
renderer_vulkan: Address vulkan surface recreation issues #56
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Finally decided to stop procrastinating on this issue and decided to take a proper look on why rotation was such a pain area on android. I think it should be actually fixed now, but needs testing to ensure. While testing I encountered and fixed the following errors:
vkQueuePresentKHR didn't handle vk::Result::eSurfaceLostKHR like vkAcquireNextImageKHR did. It is entirely possible for the rotation to occur while the window thread is presenting and it would crash when that occurred. Fixed that by handling the exception and skipping presentation of that frame. The next loop is responsible for acquiring a new image (which will recreate the swapchain).
This sadly didn't fix the rotation crashes entirely. It would still crash with the following error in logcat:
native_window_api_connect returned an error: Invalid argument (-22)
The crash occurred inside vkCreateAndroidSurfaceKHR. Reading through the code, it seems this function complains that we are trying to create 2 surface handles for the same ANativeWindow, which made me suspect that android doesn't always change the surface (current code assumes this is always the case). And lo and behold, it doesn't, so added a check to only notify the renderer if it gets changed (mainly saw it when quickly flipping the phone, so the surface dimensions stay the same)
On my device there also an additional error that can crash the app, which doesn't look related to vulkan:
android.app.RemoteServiceException$ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{32d5cff u0 org.citra.citra_emu.canary.debug/org.citra.citra_emu.utils.ForegroundService}
This might be Samsung specific, or it may not. Please test this PR and check if the crashes are fixed to confirm that
Fixes
#55