[vlc-devel] [PATCH v5 00/24] Get rid of the control command API

[Steve Lhomme]

On 2020-08-24 17:44, Rémi Denis-Courmont wrote:
> Le maanantaina 24. elokuuta 2020, 17.52.54 EEST Steve Lhomme a écrit :
>> On 2020-08-24 16:01, Rémi Denis-Courmont wrote:
>>> Le maanantaina 24. elokuuta 2020, 10.41.41 EEST Steve Lhomme a écrit :
>>>> Changes since v4:
>>>> - split the "mouse-moved" variables in 2 versions: one in video area
>>>> coordinates one in original video coordinates.
>>>
>>> We never did that because it is utterly pointless.
>>>
>>> By definition, the window coordinates can only mean anything in the window
>>> provider. And the window provider already knows those values, needs not
>>> have core callbacks to receive its own events.
>>
>> There's no "can only mean". hotkeys and gestures already interpret the
>> mouse movements. And as I already explained the fact that the video is
>> magnified 100x shouldn't mean you have to move your mouse 100x faster
> 
> Why not? If your monitor resolution is 100x times that of the original video,
> it makes perfect sense that the speed is 100x if you measure video pixel
> speed. Indeed, until recently, hotkeys did not even care about mouse
> coordinates - only clicks. And the current rare usage (VR) has always been
> done with video coordinates.

This is wrong. If you mouse your mouse one pixel left, in VR, the video 
should "rotate" by one pixel as well. It doesn't matter if your screen 
is hidpi or you magnified the video 100x.

Now we could have this viewpoint value sent to the display/audio output 
modules. Except when you change the viewpoint it may also affect your 
input source (INPUT_CONTROL_SET_VIEWPOINT, 
INPUT_CONTROL_SET_INITIAL_VIEWPOINT, INPUT_CONTROL_UPDATE_VIEWPOINT). So 
it would also make sense to transform the magnified value to a 
non-magnified value to pass to lower levels that may interpret the 
viewpoint.

It doesn't change the fact that on the rendering side (video and audio) 
that still a one pixel movement that should be perceived by the user. In 
other words, not translated to video coordinates (or back and forth 
which would lose some precision).

> Not that there are no use cases where you want the window coordinates, for
> some definition of window. In fact in some of those cases, that definition of
> window will match that of the vout_window_t. But if you don't know which
> window generated the event, that's still pretty useless.

The hidpi screen is an interresting case. If you move your mouse at a 
certain speed you would have X pixels moved on a normal screen and 2*X 
pixels moved on a 2*DPI screen. So for gesture it would make sense to 
use the value of X compared to our threshold, rather than X and 2*X 
depending on where the movement comes from.

I don't think that's a case we handle yet. We don't divide/multiply 
mouse movements based on the DPI of the screen. Maybe there should be a 
notion of "zoom" on the mouse pointer structure to solve this issue. The 
gesture would use "unzoomed" values whereas the viewpoint or others 
would use the zoomed (real pixels) values.

>> to activate the gesture. It's "window" coordinates, not "video" coordinates.
>>
>> It is like that now but it's a bug. Probably no-one ever noticed because
>> only magnify, deinterlace and transform change the mouse coordinates.
> 
> What? Of course not! Coordinate translation takes place as soon as the video
> is zoomed in or out. That's *very* common. Deinterlace is quite common too.

The fact is, transform and deinterlace are mostly handled in the GPU 
nowadays either in filters or the display module. Noone of which 
currently handle mouse events. So this feature currently depend on using 
software decoders/filters. But that's a different issue to fix.

> The odd & broken one here is the (desktop) gestures interface, which is
> rarely, if ever, used. And it should vary based on the DPI, so providing the
> window coordinates is not going to fix it anyway. It's highly questionable that
> it should even catch the VLC video window events.

We're progressing, maybe we need something else besides the video 
coordinates we currently have and which are only good for menu handling.