[vlc-devel] [PATCH 04/48] video_output: no need to check if there's a display to Stop in vout_Close

Rémi Denis-Courmont remi at remlab.net
Mon Oct 14 12:32:46 CEST 2019


That's not what I meant. I do think we will eventually need a transient state where the window is enabled but there is no display. That state would be used to preserve the window and avoid GUI glitches when changing format, ES or input.

My point is that I don't think we need, on top of that transient state, a way to bypass it by changing the format. We can just stop the current VD and *then* start a new VD with the new format.

Le 14 octobre 2019 11:18:38 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>On Sat, Oct 12, 2019, at 13:41, Rémi Denis-Courmont wrote:
>> Le perjantaina 11. lokakuuta 2019, 16.33.18 EEST Steve Lhomme a écrit
>> > vout_Close does vout_StopDisplay + vout_DisableWindow
>> > 
>> > In the case where there is no display (vout_StopDisplay not called)
>> > should still disable the window before destroying it.
>> At least historically, vout_Stop() would yield an assertion failure
>if the 
>> display was missing. And that's very much on purpose - to forbid
>> programming calling vout_Stop() on an already stopped/not-started
>> This patch should not work - or something regressed.
>Like rémi, I don't think we should have a state where the VD is stopped
>but the windows is still enabled (except when restarting, cf.
>> -- 
>> レミ・デニ-クールモン
>> http://www.remlab.net/
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:

Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191014/3912a4aa/attachment.html>

More information about the vlc-devel mailing list