Wayland Relative Pointer API Progress

x414e54 x414e54 at linux.com
Sun Jun 28 07:32:17 PDT 2015


On Wed, Jun 24, 2015 at 3:57 AM, Bill Spitzak <spitzak at gmail.com> wrote:
> 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".

Clients do not draw the mouse cursor, either the GPU (using hardware
overlays) or the WM does.

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

I was not being condescending... I am just not sure how you cannot see
why this would not work?

It is a bit of an extreme case example but:

1) User moves mouse and WM adds to clients queue then blocks mouse movement.
2) The application's render thread hangs but event thread continues.
3) Mouse does not move.

There are plenty of other issues such as the application has to load
or download something before it can render the next frame blocking the
mouse causing jerkiness and lag.

Even hiding the mouse can be irritating for users but not as
irritating as the mouse not moving for 1-2s then suddenly appearing
over the other side of the screen.

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

Maybe your computer is just underpowered so the WM drops fps?

There should be no difference between when moving a window and not
because the client is not involved directly.

I state it again there are no window managers that block mouse
movement waiting for a client.

Take the example of window resizing as that is much easier to notice.
OSX, Window, X11 and Wayland (Gnome Shell) do not sync the mouse with
the new window size.

For native GUIs Windows uses a completely different system of drawing
based on WM_PAINT events. I believe even scrollbars are drawn and
moved server side (by the WM), clients do not render scrollbars
themselves. This would be similar to the (over the top) subsurface
style approach I suggested earlier.

More information about the wayland-devel mailing list