feat: relative mouse

[ym]

No description provided.

[adamshiervani]

Because of the different OSes handles acceleration, there is a high chance that the client mouse will move out of the videoElm before the remote host will. I would suggest attaching the mouse handler area outside the video element (the dotted area without the action bar).

Maybe even both handlers can use the that outer container as the handler, as the mouse move function, is clamping the position in absolute mode to the video area.

My suggestion is not a final solution, but good enough until we get the Pointer Lock implemented

[ym]

Because of the different OSes handles acceleration, there is a high chance that the client mouse will move out of the videoElm before the remote host will. I would suggest attaching the mouse handler area outside the video element (the dotted area without the action bar).

Maybe even both handlers can use the that outer container as the handler, as the mouse move function, is clamping the position in absolute mode to the video area.

My suggestion is not a final solution, but good enough until we get the Pointer Lock implemented

Yes, I've tried that, but unfortunately Chrome only allows `pointer-lock' for sites behind TLS, and right now we only support plain HTTP for local deployment. I can probably add the feature and a simple note telling users that this feature may not work properly if TLS isn't enabled.

[adamshiervani]

Understood. What I'm trying to say is that before we get TLS up and running, we could simply expand the mouse handler bounding box, so that if there is a mismatch between the client and host mouse, it won't be too disruptive for the user.

Also, we should probably add a label saying this is Experimental to reduce the expectation a bit.

[r2lutz7]

Question: I have updated to v.0.3.8 and the relative mouse feature is currently still shown as "coming soon."
Do I need to be on the Dev Release channel to be able to enable this option?