Wayland Relative Pointer API Progress

[Bill Spitzak]

On Mon, Jul 13, 2015 at 9:48 PM, x414e54 <x414e54 at linux.com> wrote:

>
> Okay lets say for whatever reason you allow the client direct access
> to set the cursor position in a way that did not introduce any extra
> lag.
>

I'm going to ignore all this, because it is obvious that what I propose has
"lag". Avoiding lag is impossible. It is disingenious of you to try to add
an impossible requirement to my proposal and then say "your proposal is
stupid because this requirement I added is impossible!"

The ONLY difference between my proposal and "pointer lock" is that the
cursor image moves to where the "cursor_hint" as you call it is. Your
proposal requires the client to hide the cursor. Mine will be IDENTICAL if
the client hides the cursor, but leaves open the possibility of NOT hiding
the cursor. THAT'S IT!!!!!

You STILL cannot sync a scrollbar with the mouse position because the
> event loop thread should not be tied to the render loop thread and the
> call to swap buffers would be out of sync with the call to set
> position.
>

The cursor is moved by the "render loop", not the "event loop".

Either way your event loop is now completely tied into your render
> loop, meaning your render loop will also introduce extra latency to
> your event loop. Lets be extreme and say the render loop updates at
> 1fps on my computer (because it is really slow, something out of your
> application's control).
>

If the render takes one second, then the reaction to an event will be
delayed by one second. Pushing a button or moving a slider will not show
the new slider or button until one second later. It does not matter whether
pointer-lock is used, and it does not matter whether you have to hide the
cursor when using pointer-lock or you can move it (as I propose). All of
this is entirely irrelevant.

The mouse cursor now moves at 1fps and every-time I click nothing
> happens for a whole second.
>

Yes that is EXACTLY how it should work. Nothing happens for one second. And
with my proposal the mouse cursor does not slide around atop the thing that
is not moving, instead it looks a lot more like you really grabbed it. This
is exactly what I want.

If you don't think so, just don't use the pointer lock. That is not too
hard.

How is this "smooth"?
>

It's not smooth. Obviously. But it has the optical illusion of smoothness
because the cursor does not slide around atop the jumping image, instead
they jump together. I recommend you try this with a fake program if you
don't believe me.

I really could not trust that any application would be bothered to
> implement this correctly.
>

I don't trust any application to implement *anything* correctly. That is
not a good argument.


> An event loop in most applications is separate from the render loop so
> you cannot use ping/pong events.


The render loop would be sending the cursor-positioning request.

You also cannot use an update to cursor position because the cursor
> genuinely may not be moving.


You can send the cursor position request with the same coordinates as the
last one you sent.


> Also you cannot use a buffer update because the applications should
> not be required to commit a buffer that has not changed just to
> move/not move the cursor.
>

This is true of everything that is synced with a wl_surface commit request.
I should check but I believe the requirement to change the buffer to get
other effects has been fixed. If not it should be.

Furthermore you are putting too much trust into a perfectly performing
> client which are much harder to implement in practice than theory.
>

I have no idea what you mean by this. If the client has succeeded in
setting up pointer lock I think we can assume it is "performing".


> I am really not sure you understand how computers work. Are you some
> how under the impression that latency does not exist?
>

Yes of course latency exists. The existence of latency is one of the
reasons for my proposal (I also want to allow non-linear movement of the
cursor). You seem to be saying "any idea that does not remove latency is
wrong". But I'm afraid that is 100% of Wayland. The only way to remove all
latency is to do nothing.

Some older systems the client probably is involved in moving a window.
> If they do not have double buffering and draw directly to the onscreen
> frame-buffer for example.
>

Yes early Windows and pre-compositing X did this. It has nothing to do with
my proposal and Wayland does not work this way.

The reason I was discussing window movement is that I am arguing that the
reason it looks "smooth" is because Windows (and current implementations of
Wayland) move the hardware cursor in sync with the composited image, and
this position of the cursor and the position of the dragged window are
updated from the same motion event (which could have been a very long time
ago), and thus they are locked together.

This is not true of X11 as the window is moved by the window manager
process and is not in sync with the cursor being moved.

This is not visible on modern machines as they are fast enough that both
update during the vertical retrace. But it was certainly true of older
hardware from around 2000. Windows movement looked far better than X11
window movement, even if every other update such as resizing looked like
crap on both. This is due to the sync. Some X11 window managers hid the
cursor during drag to try to fix this.

Take a finger or pen for example how is that ever going to be in sync
> with moving a window?


This is true of mice and touchpads and pen tablets. The user can move them
and it is possible that the computer's reaction will lag.

I think you are considering some system where there is no need for a cursor
(but high-precision pen screens currently require a cursor, as we lack the
technology to put the image on the front surface of the top glass). But if
the cursor is hidden then my proposal is EXACTLY THE SAME as the
pointer-lock proposal! So I have no idea what you are trying to get at here.

Regardless of if the actual theme is draw client side it does not mean
> it is rendering to only one surface/view/texture. There can be many
> individual subsurfaces or views that are part of the window, which may
> be clipped or moved by the compositor or GPU without the application
> needing to be involved.
>

The Wayland design requires the client to move and resize and redraw
subsurfaces and everything is synced with commit requests.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150714/9b8c4e9c/attachment.html>