Wayland Relative Pointer API Progress

[Pekka Paalanen]

On Mon, 22 Jun 2015 15:46:41 +0900
x414e54 <x414e54 at linux.com> wrote:

> This is wrong on so many levels and probably shows you either have
> never used either Weston or Gnome Shell when they had laggy slow mouse
> issues.
> I believe Gnome has partially fixed it but there was still massive lag
> when entering/exiting some Windows and it changed over the image last
> time I checked.
> This means every so often the mouse got stuck then flew across the screen.

FWIW, Weston does not block pointer motion on client response. If a
client is lagging, the effect you will see[*] is that the cursor will
keep on moving as normal, but the cursor image will change only when
the client catches up (e.g. from arrow to hand). If the pointer is
already "gone" when the client catches up, that client cannot change
the cursor anymore (implemented with input serials).

That's the exception we make to the "every frame is perfect" rule: the
compositor cannot wait for arbitrary clients.

If the client is the one drawing and moving the cursor, the rules
change: the user is on the mercy of the client's responsiveness. Then
the "every frame is perfect" rule is in full strength: all state updates
the client sends need a way to be applied atomically to avoid the
possibility of transient visual glitches.

Which mode one should pick is a whole another question. Obviously you
can't have the benefits of both without requiring "real-time
responsiveness" from the client, in which case the choice becomes
mostly irrelevant.


Thanks,
pq

[*] There are other reasons that may stall Weston's output: a heavy GPU
task in a client can slow everything down. Those are a very different
matter and cause.