[vlc-devel] [PATCH 09/39] vout: request the display with a decoder device

[Alexandre Janniaux]

Hi,

What I wrote for the window provider basically inserts a different providing
method in vout_Create which is conveyed from the interface by a
vlc_player_SetWindowProvider function call.

It means that the vout_thread is still the one creating the window, and it is
far simpler to handle core callbacks of display windows.

I'll send a proper branch as soon as everything is supported, but you can check
a WIP state here:
https://github.com/alexandre-janniaux/vlc/commit/88ab28d920423764a47728c54f73e58377e380b2

Reversing the dependency between vout_thread and vout_window seems against what
we designed, decided and implemented from the window workshop of this year.
Ideas like vout dummy came exactly from the fact that we want the vout_thread to
be configurable before any window exists and actually runs.

About the decoder device going from the vout to the decoder, being understood
that it represents the graphics device resources location that should be used to
do the drawing and synchronize the whole pipeline on it, it seems to me a rather
good idea that it comes from the window (graphical resource allocator) and thus
the vout thread when it comes to what comes intuitively. It might not match
with simplicity or sanity, but I fail to see how. Would you have any hints?



On Thu, Oct 03, 2019 at 09:51:30PM +0300, Rémi Denis-Courmont wrote:
> Le keskiviikkona 2. lokakuuta 2019, 17.23.24 EEST Steve Lhomme a écrit :
> > NULL for now, it will turn into a video context once we pass it from the
> > decoder.
>
> In the normal playback case (not encoder), the decoder device is supposed to
> stem from the window. The window is supposed to stem from the player, via a
> yet-to-be-written player owner callback. One consequence is that the vout will
> eventually have to stem from the window, rather than the other way around in
> the current limbo.
>
> And then, it's not obvious at all that the decoder device should go from the
> vout to the decoder. It's possible, but I'm not sure that's the simplest/
> sanest approach.
>
> --
> レミ・デニ-クールモン
> http://www.remlab.net/
>
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel