<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 28, 2015 at 7:32 AM, x414e54 <span dir="ltr"><<a href="mailto:x414e54@linux.com" target="_blank">x414e54@linux.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>Clients do not draw the mouse cursor, either the GPU (using hardware<br>
overlays) or the WM does.<br></blockquote><div><br>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is a bit of an extreme case example but:<br>
<br>
1) User moves mouse and WM adds to clients queue then blocks mouse movement.<br>
2) The application's render thread hangs but event thread continues.<br>
3) Mouse does not move.<br></blockquote><div><br>Lets add the next steps:<br><br></div><div> 4) Compositor does not get a cursor position or pong request in the next 1/10 second or so.<br></div><div> 5) Compositor draws the cursor in the new position just like it does now<br><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There should be no difference between when moving a window and not<br>
because the client is not involved directly.<br></blockquote><div><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For native GUIs Windows uses a completely different system of drawing<br>
based on WM_PAINT events. I believe even scrollbars are drawn and<br>
moved server side (by the WM), clients do not render scrollbars<br>
themselves. This would be similar to the (over the top) subsurface<br>
style approach I suggested earlier.<br></blockquote><div><br></div><div>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.<br><br></div></div></div></div>