<div dir="ltr"><div><div><div>On Sun, Jul 19, 2015 at 6:06 AM, x414e54 <span dir="ltr"><<a href="mailto:x414e54@linux.com" target="_blank">x414e54@linux.com</a>></span> wrote:<br><br></div>This seems to be getting WAY off course.<br><br></div>My request is for "set_cursor_position_hint" to actually move the cursor, rather than forcing the client to make a fake cursor. It could very well move the cursor without syncing with the drawing.<br><br></div><div>I screwed up when I suggested that my proposal could also be synced with drawing (by making the set_cursor_position be latched to wl_surface commit). For some reason this then turned into a long argument, continued here apparently, about whether this is a good idea or not. Maybe it is not. But that is irrelevant because the alternative of a fake cursor FORCES you to use sync update!<br></div><div><br><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>Even with subsurfaces GUI applications really should not push their<br>
own cursors around as they cannot control the latency between the user<br>
moving the mouse and receiving the event. Think about x11 forwarding<br>
where the window is actually composited locally but running on a<br>
remote server. You would loose the benefit over using a frame based<br>
protocol such as VNC. It is not abnormal to have 50-100ms latency to a<br>
remote server. Sure you are always going to have a lag once you click<br>
a button and wait for the remote application to respond but at least<br>
the user knows where the mouse was when they clicked.<br></blockquote><div><br></div><div>Yes, obviously. This is why I am interested in a pointer-lock that only works when the mouse button is held down. I am guessing that async highlight and tooltip update is not annoying enough to be worth the delayed and intermittent cursor motion that requiring the cilent to always position the cursor would have.<br><br></div><div>When dragging on high latency, clients already have to deal with trying to guess what graphic the user was looking at when they released the button. This is not the xy of the button-release event, and might not even be the last drawing that was sent. It is really hard. However my proposal at least stops the cursor from getting ahead and further confusing the user about where the release happens.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also what Bill was talking about was syncing the exact position of the<br>
mouse to the rendered graphics (running a subsurface in synced mode)<br>
which not only means the mouse will be skipping frames you will have<br>
issues because SwapBuffers is asynchronous so you could end up<br>
overwriting the state cache for the cursor position. You would have to<br>
stick a fence in the gl command queue and wait before you called<br>
set_position. In this case your graphics pipeline would be faster if<br>
you just did a blit or texture draw because there is no CPU/GPU sync<br>
required.<br></blockquote><div><br>It sounds like you are saying that there is hardware where it is
 impossible, or at least difficult or slow, to make the cursor move in 
sync with the swap that updates the composited desktop. If this is true 
it means the compositor cannot use the cursor hardware for a subsurface,
 so in fact my proposal (without sync) will provide a more efficient way
 of moving the cursor around in pointer-lock mode.<br><br><br></div></div></div></div></div></div></div>