Wayland Relative Pointer API Progress

[Bill Spitzak]

On Sun, Jul 19, 2015 at 6:06 AM, x414e54 <x414e54 at linux.com> wrote:

This seems to be getting WAY off course.

My request is for "set_cursor_position_hint" to actually move the cursor,
rather than forcing the client to make a fake cursor. It could very well
move the cursor without syncing with the drawing.

I screwed up when I suggested that my proposal could also be synced with
drawing (by making the set_cursor_position be latched to wl_surface
commit). For some reason this then turned into a long argument, continued
here apparently, about whether this is a good idea or not. Maybe it is not.
But that is irrelevant because the alternative of a fake cursor FORCES you
to use sync update!

Even with subsurfaces GUI applications really should not push their
> own cursors around as they cannot control the latency between the user
> moving the mouse and receiving the event. Think about x11 forwarding
> where the window is actually composited locally but running on a
> remote server. You would loose the benefit over using a frame based
> protocol such as VNC. It is not abnormal to have 50-100ms latency to a
> remote server. Sure you are always going to have a lag once you click
> a button and wait for the remote application to respond but at least
> the user knows where the mouse was when they clicked.
>

Yes, obviously. This is why I am interested in a pointer-lock that only
works when the mouse button is held down. I am guessing that async
highlight and tooltip update is not annoying enough to be worth the delayed
and intermittent cursor motion that requiring the cilent to always position
the cursor would have.

When dragging on high latency, clients already have to deal with trying to
guess what graphic the user was looking at when they released the button.
This is not the xy of the button-release event, and might not even be the
last drawing that was sent. It is really hard. However my proposal at least
stops the cursor from getting ahead and further confusing the user about
where the release happens.


> Also what Bill was talking about was syncing the exact position of the
> mouse to the rendered graphics (running a subsurface in synced mode)
> which not only means the mouse will be skipping frames you will have
> issues because SwapBuffers is asynchronous so you could end up
> overwriting the state cache for the cursor position. You would have to
> stick a fence in the gl command queue and wait before you called
> set_position. In this case your graphics pipeline would be faster if
> you just did a blit or texture draw because there is no CPU/GPU sync
> required.
>

It sounds like you are saying that there is hardware where it is
impossible, or at least difficult or slow, to make the cursor move in sync
with the swap that updates the composited desktop. If this is true it means
the compositor cannot use the cursor hardware for a subsurface, so in fact
my proposal (without sync) will provide a more efficient way of moving the
cursor around in pointer-lock mode.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150720/6d72eb0b/attachment.html>