<html><head></head><body>Hi,<br><br>That can't work since the window may not have a vout or may outlive the vout, notably with audio visualization.<br><br><div class="gmail_quote">Le 4 octobre 2019 00:36:30 GMT+03:00, Alexandre Janniaux <ajanni@videolabs.io> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi,<br><br>What I wrote for the window provider basically inserts a different providing<br>method in vout_Create which is conveyed from the interface by a<br>vlc_player_SetWindowProvider function call.<br><br>It means that the vout_thread is still the one creating the window, and it is<br>far simpler to handle core callbacks of display windows.<br><br>I'll send a proper branch as soon as everything is supported, but you can check<br>a WIP state here:<br><a href="https://github.com/alexandre-janniaux/vlc/commit/88ab28d920423764a47728c54f73e58377e380b2">https://github.com/alexandre-janniaux/vlc/commit/88ab28d920423764a47728c54f73e58377e380b2</a><br><br>Reversing the dependency between vout_thread and vout_window seems against what<br>we designed, decided and implemented from the window workshop of this year.<br>Ideas like vout dummy came exactly from the fact that we want the vout_thread to<br>be configurable before any window exists and actually runs.<br><br>About the decoder device going from the vout to the decoder, being understood<br>that it represents the graphics device resources location that should be used to<br>do the drawing and synchronize the whole pipeline on it, it seems to me a rather<br>good idea that it comes from the window (graphical resource allocator) and thus<br>the vout thread when it comes to what comes intuitively. It might not match<br>with simplicity or sanity, but I fail to see how. Would you have any hints?<br><br><br><br>On Thu, Oct 03, 2019 at 09:51:30PM +0300, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le keskiviikkona 2. lokakuuta 2019, 17.23.24 EEST Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">NULL for now, it will turn into a video context once we pass it from the<br>decoder.<br></blockquote> In the normal playback case (not encoder), the decoder device is supposed to<br> stem from the window. The window is supposed to stem from the player, via a<br> yet-to-be-written player owner callback. One consequence is that the vout will<br> eventually have to stem from the window, rather than the other way around in<br> the current limbo.<br><br> And then, it's not obvious at all that the decoder device should go from the<br> vout to the decoder. It's possible, but I'm not sure that's the simplest/<br> sanest approach.<br><br> --<br> レミ・デニ-クールモン<br> <a href="http://www.remlab.net/">http://www.remlab.net/</a><hr> vlc-devel mailing list<br> To unsubscribe or modify your subscription options:<br> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></blockquote><hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>