<div dir="ltr">On Mon, Jul 13, 2015 at 9:48 PM, x414e54 <span dir="ltr"><<a href="mailto:x414e54@linux.com" target="_blank">x414e54@linux.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Okay lets say for whatever reason you allow the client direct access<br>
to set the cursor position in a way that did not introduce any extra<br>
lag.<br></blockquote><div><br></div><div>I'm going to ignore all this, because it is obvious that what I propose has "lag". Avoiding lag is impossible. It is disingenious of you to try to add an impossible requirement to my proposal and then say "your proposal is stupid because this requirement I added is impossible!"<br><br></div><div>The ONLY difference between my proposal and "pointer lock" is that the cursor image moves to where the "cursor_hint" as you call it is. Your proposal requires the client to hide the cursor. Mine will be IDENTICAL if the client hides the cursor, but leaves open the possibility of NOT hiding the cursor. THAT'S IT!!!!!<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You STILL cannot sync a scrollbar with the mouse position because the<br>
event loop thread should not be tied to the render loop thread and the<br>
call to swap buffers would be out of sync with the call to set<br>
position.<br></blockquote><div><br></div><div>The cursor is moved by the "render loop", not the "event loop".<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Either way your event loop is now completely tied into your render<br>
loop, meaning your render loop will also introduce extra latency to<br>
your event loop. Lets be extreme and say the render loop updates at<br>
1fps on my computer (because it is really slow, something out of your<br>
application's control).<br></blockquote><div><br></div><div>If the render takes one second, then the reaction to an event will be delayed by one second. Pushing a button or moving a slider will not show the new slider or button until one second later. It does not matter whether pointer-lock is used, and it does not matter whether you have to hide the cursor when using pointer-lock or you can move it (as I propose). All of this is entirely irrelevant.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The mouse cursor now moves at 1fps and every-time I click nothing<br>
happens for a whole second.<br></blockquote><div><br></div><div>Yes that is EXACTLY how it should work. Nothing happens for one second. And with my proposal the mouse cursor does not slide around atop the thing that is not moving, instead it looks a lot more like you really grabbed it. This is exactly what I want.<br><br></div><div>If you don't think so, just don't use the pointer lock. That is not too hard.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How is this "smooth"?<br></blockquote><div><br>It's not smooth. Obviously. But it has the optical illusion of smoothness because the cursor does not slide around atop the jumping image, instead they jump together. I recommend you try this with a fake program if you don't believe me.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I really could not trust that any application would be bothered to<br>
implement this correctly.<br></blockquote><div><br></div><div>I don't trust any application to implement *anything* correctly. That is not a good argument.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>An event loop in most applications is separate from the render loop so<br>
you cannot use ping/pong events.</blockquote><div><br></div><div>The render loop would be sending the cursor-positioning request.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You also cannot use an update to cursor position because the cursor<br>
genuinely may not be moving.</blockquote><div> <br></div><div>You can send the cursor position request with the same coordinates as the last one you sent.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also you cannot use a buffer update because the applications should<br>
not be required to commit a buffer that has not changed just to<br>
move/not move the cursor.<br></blockquote><div><br></div><div>This is true of everything that is synced with a wl_surface commit request. I should check but I believe the requirement to change the buffer to get other effects has been fixed. If not it should be.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Furthermore you are putting too much trust into a perfectly performing<br>
client which are much harder to implement in practice than theory.<br></blockquote><div><br></div><div>I have no idea what you mean by this. If the client has succeeded in setting up pointer lock I think we can assume it is "performing".<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""></span>I am really not sure you understand how computers work. Are you some<br>
how under the impression that latency does not exist?<br></blockquote><div><br></div><div>Yes of course latency exists. The existence of latency is one of the reasons for my proposal (I also want to allow non-linear movement of the cursor). You seem to be saying "any idea that does not remove latency is wrong". But I'm afraid that is 100% of Wayland. The only way to remove all latency is to do nothing.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some older systems the client probably is involved in moving a window.<br>
If they do not have double buffering and draw directly to the onscreen<br>
frame-buffer for example.<br></blockquote><div><br></div><div>Yes early Windows and pre-compositing X did this. It has nothing to do with my proposal and Wayland does not work this way.<br><br></div><div>The reason I was discussing window movement is that I am arguing that the reason it looks "smooth" is because Windows (and current implementations of Wayland) move the hardware cursor in sync with the composited image, and this position of the cursor and the position of the dragged window are updated from the same motion event (which could have been a very long time ago), and thus they are locked together.<br><br></div><div>This is not true of X11 as the window is moved by the window manager process and is not in sync with the cursor being moved.<br><br></div><div>This is not visible on modern machines as they are fast enough that both update during the vertical retrace. But it was certainly true of older hardware from around 2000. Windows movement looked far better than X11 window movement, even if every other update such as resizing looked like crap on both. This is due to the sync. Some X11 window managers hid the cursor during drag to try to fix this.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Take a finger or pen for example how is that ever going to be in sync<br>
with moving a window?</blockquote><div><br>This is true of mice and touchpads and pen tablets. The user can move them and it is possible that the computer's reaction will lag.<br><br></div><div>I think you are considering some system where there is no need for a cursor (but high-precision pen screens currently require a cursor, as we lack the technology to put the image on the front surface of the top glass). But if the cursor is hidden then my proposal is EXACTLY THE SAME as the pointer-lock proposal! So I have no idea what you are trying to get at here.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regardless of if the actual theme is draw client side it does not mean<br>
it is rendering to only one surface/view/texture. There can be many<br>
individual subsurfaces or views that are part of the window, which may<br>
be clipped or moved by the compositor or GPU without the application<br>
needing to be involved.<br></blockquote><div><br></div><div>The Wayland design requires the client to move and resize and redraw subsurfaces and everything is synced with commit requests.<br><br></div></div></div></div>