[vlc-devel] [PATCH] libvlc: add API to propagate mouse move and down/up events
remi at remlab.net
Tue May 6 20:59:44 CEST 2014
Le mardi 6 mai 2014, 17:45:26 Felix Paul Kühne a écrit :
> >> You don't know which vmem instance you are referring to. This is totally
> >> broken if you have more than one window.
> This is absolutely true.
> However: libvlc_video_get_cursor() already uses the same pattern I do in
> this patch. It lets you access the video output by N.
That is a known design bug that should not be repeated. I don't remember why
get_cursor() was even needed way back; it seems useless/unusable in practice
or almost. But at least it exhibits dubious correctness in returning the
correct coordinates for _the_last_ focused video area.
> Additionally, if you consider the remainder of the video API listed in
> libvlc_medoa_player.h, it appears to me as if more than one video output
> per libvlc instance was never a supported scenario.
You've got to be kidding. libvlc_video_get_size() supports it (for meta data)
The vmem API supports it too; there was even a discussion a few months back on
how to add new per-vmem instance functions.
Also several video functions apply correctly to all video outputs, regardless
of how many there are.
> I fully agree, however, this is not really feasible in the scenario targeted
> by the patch.
vmem is neither designed nor capable of supporting video rendering (it was
designed by Sam to feed video post-processing filters). Mouse handling is not
the (worst) limitation inhibiting proper rendering support. Adding a function
pretending the contrary is misleading to external developers and plain wrong.
> For the NPAPI plugin, we support a special rendering mode called
> “windowless”, which does not make use of the existing libvlc vout modules.
That is a bug in the NPAPI plugin and a gap in modules/video_output/, not a
problem in LibVLC at this point. Using vmem as it currently stands cannot work
correctly for that scenario, regardless of this patch.
More information about the vlc-devel