Wayland Relative Pointer API Progress

[x414e54]

Hi I have been away for a while and quite busy so I did not get a
chance to response.

On Tue, Apr 28, 2015 at 3:46 AM, Bill Spitzak <spitzak at gmail.com> wrote:
> No, I absolutely 100% disagree.
>
> Synchronized updating so things don't vibrate or shift is more important
> than FPS. It is even stated as part of Wayland's basic design criteria:
> "every frame is perfect".

Wow... no.... seriously...

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.

Usually this is what happens when you have people who do not actually
consider usability studies and HF&E.


If you really want to start a quote war there is also the quote:
 "by which I mean that applications will be able to control the
rendering enough that we'll never see tearing, lag, redrawing or
flicker.".

There is one key word in there "lag". Lag is an inevitable part of
computing you cannot guarantee when an application will get CPU time
to processes events and sync with the compositor.

So in your system the compositor would have to block mouse cursor
movement until an application had dispatched and processed its events.
Literally in this instance the user would be moving the physical mouse
and nothing happening on screen. Which is why (I assume) for moving
windows the compositor does 100% of the work. Because if the
application was involved there would be lagging movement whilst the
application was switched out or doing something else.

It does not work which is why no Window Managers ever do or should do this.