Wayland Relative Pointer API Progress

[Bill Spitzak]

On Sun, Jun 28, 2015 at 7:32 AM, x414e54 <x414e54 at linux.com> wrote:

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

Yes, I want to allow clients to use this CPU/WM support. Currently the
client *has* to draw the cursor (and hide the hardware one) to sync it's
position with the drawing. If instead the client just *moves* the cursor,
then the cursor is actually drawn by the compositor like you say.


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

Lets add the next steps:

 4) Compositor does not get a cursor position or pong request in the next
1/10 second or so.
 5) Compositor draws the cursor in the new position just like it does now

I am just trying to allow clients to take advantage of sync if they are
capable of it. Falling back to the previous behaviour is acceptable. In
fact this is better than clients hiding the cursor and drawing their own in
that such fallbacks work. A frozen client drawing it's own cursor means the
cursor will appear only when the user moves it out of the window, and at a
pretty unpredictable place, and the old cursor image will still be there on
screen.

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

Whether a client is involved "directly" should not be visible to a user.
Yes I'm sure this works this way on Windows due to simplistic
implementation of the compositor, and that is why resizing does not work
this way (as you noticed). However that does not negate the fact that this
makes the window positioning look better, even on "underpowered" computers.
What I am proposing is that clients be able to take advantage of this to
make other interactions besides window dragging be perceptually smoother.

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

No that is not how it works. All rendering is done on the client side in
modern Windows. It is done by system libraries but they are running in the
client process and drawing into a memory-mapped image just like Wayland
does.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150629/eb60f9f5/attachment.html>