MoltenVK does a lazy fetch of the drawable only when it's being modified, so waitToRender() is completely ineffective as is. Rendering a small empty overlay in waitToRender() forces the next drawable wait to happen in waitToRender(), before we pick the current frame to render. This removes one display refresh period of latency when using V-sync.
Direct-to-display mode on some Macs (M4 Mac Mini) can retain our drawables, which cuts the frame rate in half if we're in double-buffered mode.
We don't want to use triple-buffered mode all the time because it increases latency when used if not required, so detect delayed presentation and enable it on the fly if needed.
Every renderer except SDL had opted-in for testing due to various
quirks discovered over the years, so just do away with this option
and test all renderers.
In addition to resolving issues with mixing HDR and SDR displays and moving
between them while streaming, it also allows streaming HDR content to an SDR
display with tone mapping handled transparently by libplacebo.
Vulkan H.264/HEVC video decoding isn't supported with Fedora's Mesa binaries due to
patent issues, so only the VAAPI/DRM-PRIME import path was tested locally with ANV.
HDR video is getting tonemapped to my SDR monitor reasonably, so HDR output probably
works with GameScope but I haven't confirmed yet.
See #1117
Cameron Gutman
ns6089
Dylan Frankcom