The Qt UI continuously redrawing prevents libdecor-gtk's glib dispatch loop
from ever returning since it constantly posts new messages to draw again.
The result is that Moonlight randomly hangs (with the spinner still animating)
at the "Starting app..." phase of connection establishment and never proceeds
until the livelock is broken by loss of focus, hiding the window, or similar.
For posterity, the hanging stack:
QtWaylandClient::QWaylandWindow::waitForFrameSync (this=this@entry=..., timeout=timeout@entry=...) at qwaylandwindow.cpp:891
QtWaylandClient::QWaylandGLContext::swapBuffers (this=..., surface=...) at qwaylandglcontext.cpp:494
QRhiGles2::endFrame (this=..., swapChain=..., flags=...) at qrhigles2.cpp:2390
QRhi::endFrame (this=..., swapChain=..., flags=...) at qrhi.cpp:11600
QSGGuiThreadRenderLoop::renderWindow (this=..., window=...) at qsgrenderloop.cpp:714
QQuickWindow::event (this=..., event=...) at qquickwindow.cpp:1663
QCoreApplication::notifyInternal2 (receiver=..., event=...) at qcoreapplication.cpp:1126
QCoreApplication::sendEvent (receiver=..., event=...) at qcoreapplication.cpp:1571
QPlatformWindow::deliverUpdateRequest (this=...) at qplatformwindow.cpp:831
QObject::event (this=..., e=...) at qobject.cpp:1480
QCoreApplication::notifyInternal2 (receiver=..., event=...) at qcoreapplication.cpp:1126
QCoreApplication::sendEvent (receiver=..., event=...) at qcoreapplication.cpp:1571
QCoreApplicationPrivate::sendPostedEvents (receiver=..., event_type=..., data=...) at qcoreapplication.cpp:1926
postEventSourceDispatch (s=...) at qeventdispatcher_glib.cpp:248
g_main_dispatch (context=...) at gmain.c:3591
g_main_context_dispatch_unlocked (context=...) at gmain.c:4451
g_main_context_iterate_unlocked (context=context@entry=..., block=block@entry=..., dispatch=dispatch@entry=..., self=...) at gmain.c:4516
g_main_context_iteration (context=..., context@entry=..., may_block=may_block@entry=...) at gmain.c:4582
libdecor_plugin_gtk_dispatch (plugin=..., timeout=...) at libdecor-gtk.c:509
Wayland_PumpEvents (_this=...) at SDL_waylandevents.c:610
Wayland_GLES_LoadLibrary (_this=..., path=...) at SDL_waylandopengles.c:51
SDL_GL_LoadLibrary_REAL (path=...) at SDL_video.c:4735
SDL_RecreateWindow (window=..., flags=...) at SDL_video.c:2796
GLES2_CreateRenderer (renderer=..., window=..., create_props=...) at SDL_render_gles2.c:2329
SDL_CreateRendererWithProperties_REAL (props=props@entry=...) at SDL_render.c:1126
SDL_CreateRenderer_REAL (window=..., name=...) at SDL_render.c:1287
SDL_CreateRenderer_REAL (window=..., idx=..., flags=...) at sdl2_compat.c:5986
EGLRenderer::initialize (this=..., params=...) at eglvid.cpp:445
FFmpegVideoDecoder::initializeRendererInternal (this=..., renderer=..., params=...) at ffmpeg.cpp:323
FFmpegVideoDecoder::createFrontendRenderer (this=..., params=..., useAlternateFrontend=...) at ffmpeg.cpp:426
FFmpegVideoDecoder::completeInitialization (this=..., decoder=..., requiredFormat=..., params=..., testMode=..., useAlternateFrontend=...) at ffmpeg.cpp:486
FFmpegVideoDecoder::tryInitializeRenderer(AVCodec const*, AVPixelFormat, _DECODER_PARAMETERS*, AVCodecHWConfig const*, IFFmpegRenderer::InitFailureReason*, std::function<IFFmpegRenderer* ()>)
(this=..., decoder=..., requiredFormat=..., params=..., hwConfig=..., failureReason=..., createRendererFunc=...) at ffmpeg.cpp:1200
FFmpegVideoDecoder::tryInitializeHwAccelDecoder (this=..., params=..., pass=..., terminallyFailedHardwareDecoders=...) at ffmpeg.cpp:1544
FFmpegVideoDecoder::initialize (this=..., params=...) at ffmpeg.cpp:1701
Session::chooseDecoder (vds=..., renderer=..., window=..., videoFormat=..., width=..., height=..., frameRate=..., enableVsync=..., enableFramePacing=..., testOnly=..., chosenDecoder=...) at session.cpp:322
Session::getDecoderAvailability (window=..., vds=..., videoFormat=..., width=..., height=..., frameRate=...) at session.cpp:498
Session::initialize (this=..., qtWindow=...) at session.cpp:755
We should be using the EGL renderer's colorspace and color range
rather than the backend renderer's for fallbacks. The former is
what actually gets passed to the host PC during stream init.
Huge thanks to @oliverlj for identifying this longstanding bug.
This is likely responsible for many different issues with the DRM renderer randomly failing.
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.
Versions of sdl2-compat prior to 2.32.64 (and native SDL3) won't
set the grab flag if grabbing the keyboard fails, even though the
compositor still may be exclusively passing system keys to us via
some external configuration by the user. This causes the super key
to not be sent to the host, because we think the client OS will
consume it and don't want to duplicate the input.
Fixes#1900
Cameron Gutman