[vlc-devel] [PATCH 00/16] VR/360 navigation, new set

[Steve Lhomme]

On Wed, Nov 9, 2016 at 7:29 PM, Thomas Guillem <thomas at gllm.fr> wrote:
>
>
> On Wed, Nov 9, 2016, at 19:21, Rémi Denis-Courmont wrote:
>> Le keskiviikkona 9. marraskuuta 2016, 19.02.37 EET Thomas Guillem a écrit
>> :
>> > On Wed, Nov 9, 2016, at 18:58, Rémi Denis-Courmont wrote:
>> > > Le keskiviikkona 9. marraskuuta 2016, 18.32.54 EET Thomas Guillem a écrit
>> > >
>> > > > Hello, we propose a new set of patches for VR/360 navigation.
>> > > >
>> > > > The first commit changed quite a lot:
>> > > >  - vout_SetViewpoint() is renamed to vout_UpdateViewpoint(). This new
>> > > >
>> > > > function allow now to increment a viewpoint to the one that is currently
>> > > > used by the vout.
>> > >
>> > > That seems like a step backward to me. Functions for incremental changes
>> > > instead of proper setters - we have been there done that already several
>> >
>> > There is also a setter.
>>
>> I don´t see the point in having both. In practice, there either only be
>> one
>> user so that atomicity and arbitration are useless, or there will be an
>> upper
>> layer to mediate (presumably the input manager), or both.
>
>
> With libvlc, there will be only one user, OK.

Actually there might be more than one. I'm not sure it's supposed to
be thread safe (there's no thread protection though). But even if
there are plenty we keep track of the previous set value so a
getter/setter is possible there if there's only a setter on the vout.

> For Desktop, there can be more: the vout that handle the mouse events
> and the hotkeys interface that control the arrow keys.

This is the main problem here. If you move in the "world" with your
mouse and then do it with the keyboard, they have no idea what's the
current position. An incrementer (rather than a setter) avoids this
issue because they both need to send a differential value compared to
the previous state. If we only have a setter, we need a getter. Or we
could merge the mouse and keyboard handling for the navigation. I
tried such a solution with these 2 patches:
https://github.com/robUx4/vlc/commit/933c1e42d6d6d097e686d2e33927e31feb1634d1
https://github.com/robUx4/vlc/commit/2dc7ecba65ff0062696f95f7ddb1b3be2556fa53

Another option might be to handle the VR navigation through libvlc,
which keeps track of the previous state.

There's still a problem though. Without getters we also don't know if
the video playing is using a non-flat projection and so if the
keyboard/mouse should behave that way or not. We could register for
"projection" changes. But we still don't know the initial state.
(which brings a side issue, can we have var_AddCallbackWithInit() to
avoid this?)


>>
>> --
>> Rémi Denis-Courmont
>> 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:
> https://mailman.videolan.org/listinfo/vlc-devel