On Mon, 22 Jun 2015 15:46:41 +0900 x414e54 <x414...@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. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
