On most platforms, the Qt interface is started in its own thread and the
VLC interface startup routine needs to wait for the Qt interface to be
ready before giving the control back to libvlc.
On MacOS, the interface is currently started into the main thread
directly because of the platform constraints of Qt, blocking libvlc and
enforcing the startup of Qt synchronously.
Because of that, the state lock was never given back, and the window,
started from a different thread, was never able to lock it to check that
the interface is correctly started.
The correct fix should be to make the Qt interface start correctly as in
other platforms, but current attempts at making it a reality have
failed. In particular, it doesn't seem possible to dispatch the startup.
The changes here keep the current workaround, allowing application
developers to check the behaviour on MacOS.
It is not used in POSIX systems. On other system it probably don't make a
difference anymore, only Windows has actual useful values for
VLC_THREAD_PRIORITY_XXX. The synchronization is more important than having some
threads called more often than others.
In the case where compositor fails to start the MediaLib object is created then
destroyed using a deleteLater, but the destructor was never called as the main
loop was never started.
see e967f81f6a.
note, this does **not** affect cat-based module selection items
(of which there are just three in use by the core), since that
mechanism uses subcats not cats.
The composition works as follow:
* Both the interface and the video are rendered in an offscreen window (using
X11 composite extension)
* We register to damage event (x11 damage extension) to get notified when the
content of the offscreen video window change. When we receive a damage event
we ask the rendering part of the composition to refresh
* The interface is rendered in the offscreen surface using a RenderControl, when
the interface do render, the composition is asked to refresh
* A dedicated thread is spawned to do the rendering, upon a refresh event it
will take the pictures from the offscreen surface and blend them into the
actual window using X11 render extension. Using a separated thread from Qt
ensure that the rendering of the video will not be stalled if Qt thread is
busy.
* The damage events are listened on a separate X11 connection and on a separate
thread than Qt main thread (here the rendering thread). This allows to receive
theses events independently from Qt (in case the Qt thread is stalled). Note
that it is not possible to peek in qt X11 event queue from a non gui thread as
the QX11Info::peekEventQueue is no longer thread safe since 5.12.
fixes: #25627, #22155
some compositor requires to set Qt Attributes before Qt application
is started such as selecting the right graphical backend (ie: dcomp needs to set
OpenGLES). And some compositor needs know wich QPA is in use (ie: x11 vs
wayland), this can only be known after QApp is started.
Co-authored-by: Guillaume Nicolussi Castellan <nullgemm@videolabs.io>
The config "advanced" flag was unused and has been removed by
6a7a137f7b.
It has been removed from many add_*() macros, but not all. Remove it
from the remaining macros.
both the intf and the vout window reference the qt interface structure
it will only be released once not used by both modules, this way the windows
continues to exists if the interface is closed before.
When the interface module is released before the vout window, the qml view and
the associated resources are unloaded from the compositor.
fix: #25600
Fatih Uzunoglu
Steve Lhomme
Johannes Kauffmann
Benjamin Arnaud
Pierre Lamot
Leon Vitanos
Alexandre Janniaux
Rémi Denis-Courmont
Lyndon Brown
Prince Gupta
Hugo Beauzée-Luyssen
Romain Vimont