[vlc-devel] [vlc-commits] video_output: win32: fix recursive call to vout_display_SendEventDisplaySize
remi at remlab.net
Mon May 28 18:25:39 CEST 2018
Le lundi 28 mai 2018, 10:38:23 EEST Steve Lhomme a écrit :
> vlc | branch: master | Steve Lhomme <robux4 at ycbcr.xyz> | Mon May 28 09:35:58
> 2018 +0200| [39ee73994e860bfbfc45d2a3ac51e50d8a799e5d] | committer: Steve
> video_output: win32: fix recursive call to vout_display_SendEventDisplaySize
Recursive??? I don't see any recursive call here, before or after a4942. Do
you mean live-looping?
> A changing value may be receive while another one is being treated,
> resulting in an infinite loop (via event calls).
That wouldn't be a regression from a4942. That would be much much more likely
to occur with a4942, but that would be pre-existinging... That means 3.0 still
needs fixing too.
And then... I can readily believe (although I have obviously not tested) that
this fixes video playback with the Qt or skin engine window providers.
Moreover I am obviously in favor of removing display-size events from display
plug-ins as far as possible. There are multiple reasons:
- it feels like the job of the window provider,
- it avoids duplicating code in display plug-ins,
- it avoids conflicts and races like this patch tries to address.
However I doubt that this patch will work with LibVLC embedded video, or with
stand-alone (non-embedded) video at this point.
Specifically as far as I know LibVLC on Windows still uses the "my" old much
too simplistic "drawable" plug-in. It is incapable of sending the window size
events, or really any events. If it is not used by LibVLC, it should be
Likewise, I cannot find any window size events in the case of non-embedded
video, because there are no proper Win32 window provider plug-in at all so far
that I would be aware of. There should most probably be one such plug-in for
the reasons noted above, but there is not so far.
The bug is probably older than you think and it is probably still present.
More information about the vlc-devel