Pierre Lamot authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

some models like the groupModel can contain heterogeneous MLItem

Pierre Lamot authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

this function allows to run lambdas on the ML thread, this should be used to
perform operation that requires to call vlc_ml_xxx functions as vlc_ml_xxx
should *not* be called from the UI thread

obj: this is the instance of the calling QObject, we ensure that this object is
still live when calling the ui callback, if this object gets destroyed the task
is canceled

mlCb: this callback is executed in a background thread (thread pool), it takes
as arguments the instance of the medialibrary, and a context, the context can be
modified to pass data to the UI callback

uiCB: this callback is executed on the Qt thread, it takes as first argument the
id of the tasks, and as second argument the context that was created for the ML
callback

queue: this allow the task to be ran on a specific thread, when this parameter
isn't provided, the task can be scheduled on any thread.

Ctx is the type of context, this context is created by the runner and passed
sequentially to the ML callback then to UI callback, the ML callback may modify
its properties as a way to pass data to the UI callback

⚠ the ml callback **SHOULD NOT** capture the obj object or point to its
properties by reference, as the obj object may potentially be destroyed when the
function is called

the ui callback **MAY** capture the object obj as we will ensure that the object
still exists before calling the callback

the uiCb **MAY NOT** be called if the object obj is released earlier

anything stored int the context Ctx **MUST** auto release when the context is
destroyed

sample usage:

```
    //structure used to pass data from the ML thread to the UI thread
    struct Ctx {
        bool success;
    };
    m_mediaLib->runOnMLThread<Ctx>(
    //reference to the object making the call, this is used to ensure that
    //the caller still exists before calling the UI callback
    this,
    //ML thread, data needed from the caller are passed in the capture of the lambda
    //capturing this or any of its member is not allowed here
    //the callback have in parametters the ml instance and a context that will be shared with
    //the UI callback
    [url, indexed](vlc_medialibrary_t* ml, Ctx& ctx)
    {
        int res;
        if ( indexed )
            res = vlc_ml_add_folder(  ml, qtu( url ) );
        else
            res = vlc_ml_remove_folder( ml, qtu( url ) );
        ctx.success = (res == VLC_SUCCESS);
    },
    //UI callback, capturing this is allowed, (runOnMLThread will ensure that `this`
    //still exists at this point
    //the callback has as parametters the request id and the shared context
    [this, indexed](quint64, Ctx& ctx){
        if (ctx.success)
        {
            m_indexed = indexed;
            emit isIndexedChanged();
        }
    },
    //allow to specify if the task should be run on a specific thread, null (default) will run on any thread
    "ML_FOLDER_ADD_QUEUE");
```

Prince Gupta authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

fixes drag'ndrop in PlaylistView

Prince Gupta authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

place it such that it won't interfere with "focus" rect of
PlaylistDelegate

Prince Gupta authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

fixes binding loop on implicit height

This is no longer useful.

This is no longer needed, and prevents adding support for RandR output
selection.

This removes the window configuration parameter from
vout_window_Enable(). The initial configuration is now set when the
window is created, and updated with the regular functions:
vout_window_SetSize(), vout_window_SetFullScreen() and
vout_window_UnsetFullScreen().

This reconciles the window configuration with the full-screen output
selection: if the window provider supports output selection, it can
simply ignore the full-screen flag in the configuration.

In practice, this makes no differences in the GL and splitter cases,
which were creating and enabling the window together. In the vout
case, this actually enables some small simplifications.

This change does not affect the module interface: the window
configuration is still passed via the enable() callback. However window
provider can choose to ignore all parameters other than the decoration
flag. Dimensions is already provided by the resize callback, and
full-screen status via set_fullscreen and unset_fullscreen callbacks.

It should be possible to remove the dimensions and full-screen flag
from the window configuration completely, but that is left for further
work, as it would affect many different modules.

This restores the configuration parameter to vout_window_New(). This is
at least necessary to initialise the decoration flag which is otherwise
constant.

This change tracks changes requested to the window that affect the
configuration, namely requested dimensions and non-specific full-screen
mode. This will be used in further changes.

This is needed afterwards. No functional changes.

No functional changes.

No functional changes.

No function changes.

No functional changes.

As of the previous change, we always have an original format except at
the very beginning before the first attempt to start a display.

This allows the window size to be updated when the display gets started
in a vout that has an already enabled window. This also avoids taking
the display lock whenever compute the window size.

This essentially reverts commit 3784e706.

The window can be enabled even though the video output. In that case,
EnableWindowLocked() tries to adjust the window size with the common
vout_UpdateWindowSizeLocked() function. This relies on sys->original
internally, unlike the case whereby the window is disabled.
Consequently sys->original must already reflect the new format. This
change moves the update of sys->original backward to meet the
requirement.

The flip side is of course that the format gets updated even if
enabling the (disabled) window fails. Luckily this has no significance
as there is no active display using either the old (stopped) or new
(failed) formats.

Note that the bug fixed here is hidden by another bug. In practice,
the window size update is skipped entirely by the code from 3784e706
as there is no display (and before 3784e706, this would be
undefined behaviour).

As per earlier mailing list discussion, the display configuration is
supposed to be retrieved when (re)starting the video output. It should
not matter whether the window was disabled or still enabled.

This retains the original video format after the display is closed. The
main motivation for this is that the window needs a format to determine
its size, and to translate mouse coordinates, both of which can happen
after the display has been stopped.

Even though the format will be stale, this resolves several data races
in a simpler and saner way than checking if the display exists (which
requires the display lock).

It is inconditionally freed when the vout is destroyed - even if the
vout was not successfully started even once - so it had better not
contain garbage.

Admittedly it is in practice implicitly zeroed by vlc_custom_create()
so this is really more of a clean-up than a real fix.

Romain Vimont authored 3 years ago and Romain Vimont committed 3 years ago

The deadline computation was shared between the vout thread function and
DisplayPicture(), both by hacking the return value (VLC_EGENERIC meaning
"wait") and using an output parameter, to handle 3 possible cases:
 - VLC_SUCCESS: do not wait
 - VLC_EGENERIC and deadline set: wait for deadline
 - VLC_EGENERIC and deadline not set: wait but no deadline is known

In case of VLC_EGENERIC, the vout thread function computed the max
between the returned value and 100ms.

Simplify by computing the expected deadline from DisplayPicture()
directly.

This code is already handled in vout_Request().

Fixes #26394

Refs #26394

This is not a failure. This is a perfectly normal and expected
situation. If PCM also fails, we will then print an error message.