skins2: skin_main: fix window closing after interface
The interface cannot be closed before the vout_window_t object is disabled, since the playlist/player is running from outside the interfaces. When it happens, a warning was raised from skins2 and the OpenGL code would stay stuck waiting for xcb events, preventing the full closing of the interface resources and delaying the close of the application itself. This commit ensures that no skins2 window is enabled before leaving the Close function from the interface, and no new skins2 window will be enabled in a racy pattern while or after the Close function from the interface is running. The issue was highlighted in previous commit, including the commit 04409ebd which required in its commit description that interface modules should outlive the vout window instances they provide, but didn't provide a mechanism to do so. The added mutex was removed in 6083d3f1 because it was useless as-is. This commit adds a reference count of opened window, and a wait for this reference count to reach zero before ending the interface Close() function, which justify the use of a mutex. Note also that this patch uses the Enable/Disable lifecycle of the window to manage the reference count and skins2 resources, because there is an inversion between the playlist destruction and the interface destruction. We cannot wait for the vout_window_t object to be destroyed while we're waiting in the interface Close(), since the vout is potentially reused up to the playlist destruction (or more precisely, input resource destruction) which can only happen after every interface is destroyed. The implementation here is a bit different to what has been done for other interfaces like Qt. The Qt interface is creating a new libvlc object and stashes the interface state there, while refcounting it. It means that the interface implementation itself will continue to exist even if the interface object is dead. It has particular benefit when the interface is not the usual interface but a dialog provider one. The submitted approach here tries to keep the lifecycle of the interface tied together with its object, to simplify the use of its object for variable or logging, and avoid unnecessary object allocation.
Loading
Please register or sign in to comment