Wayland Relative Pointer API Progress

[Bill Spitzak]

On Sun, Jun 21, 2015 at 11:46 PM, x414e54 <x414e54 at linux.com> wrote:

> 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.
>

You do not seem to be understanding in the least what I am asking for.

There is one key word in there "lag".
>

I am not introducing any lag. If the client takes 1/2 second to draw the
result of a mouse movement, it will still take 1/2 second under my scheme.
Exactly the same amount of lag. However in my scheme the cursor will be
drawn in the correct place atop the dragged object, thus satisfying the
"every frame is perfect" requirement while not changing anything about
"lag".


> 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


Yes, despite your attempt to be condescending, you are accurately
describing EXACTLY what I want!

"nothing happening on the screen" is BETTER than "the wrong thing is drawn
on the screen".

Just like all other interaction such as window raising the compositor can
certainly time out and fake it if it appears the client is dead. I also
thought it might be ok to limit sync mouse cursor to times when the button
is down, and make it optional for the client, by some slight modifications
to the proposed "pointer lock" api. But you may be correct (even though you
are pertending you are wrong) that it is desirable even when moving the
mouse, as it would allow the program to highlight fine detail hit targets.
This is useful in complex geometry to make it easier to pick things that
are close together. Current programs either require the user to hold the
mouse still for a split second to make sure the correct thing will be
picked on click, or complex things like Maya typically draw their own
manipulator to force sync.

. Which is why (I assume) for moving
> windows the compositor does 100% of the work.


The compositor is doing the window moving so that it can implement
snapping. The client does not have sufficient information to do this.

I sure hope it is not because somebody said "Wayland is too slow to do this
any other way". That would be really sad if the developers of Wayland
thought that.

Because if the
> application was involved there would be lagging movement whilst the
> application was switched out or doing something else.
>

The application is involved already. Window dragging will not start until
the application responds with the drag request.


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

Really? Simple experiments show that Windows does this when dragging a
window (drag a window really fast and spot where it drew the cursor, it
draws is many fewer times than if you move the mouse the same speed without
dragging, and perfectly locked to the window). This is almost 100% of the
reason people think Windows drags windows more smoothly than X11.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150623/f4abf2a6/attachment.html>