<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 21, 2015 at 11:46 PM, 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">Hi I have been away for a while and quite busy so I did not get a<br>
chance to response.<br>
<span><br>
On Tue, Apr 28, 2015 at 3:46 AM, Bill Spitzak <<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>> wrote:<br>
> No, I absolutely 100% disagree.<br>
><br>
> Synchronized updating so things don't vibrate or shift is more important<br>
> than FPS. It is even stated as part of Wayland's basic design criteria:<br>
> "every frame is perfect".<br>
<br>
</span>Wow... no.... seriously...<br>
<br>
This is wrong on so many levels and probably shows you either have<br>
never used either Weston or Gnome Shell when they had laggy slow mouse<br>
issues.<br></blockquote><div><br></div><div>You do not seem to be understanding in the least what I am asking for.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is one key word in there "lag".<br></blockquote><div><br></div><div class="gmail_quote">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".<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So in your system the compositor would have to block mouse cursor<br>
movement until an application had dispatched and processed its events.<br>
Literally in this instance the user would be moving the physical mouse<br>
and nothing happening on screen</blockquote><div><br></div><div>Yes, despite your attempt to be condescending, you are accurately describing EXACTLY what I want!<br><br></div><div>"nothing happening on the screen" is BETTER than "the wrong thing is drawn on the screen".<br><br></div><div>Just like all other interaction such as window raising the compositor can certainly time out and fake it if it appears the client is dead. I also thought it might be ok to limit sync mouse cursor to times when the button is down, and make it optional for the client, by some slight modifications to the proposed "pointer lock" api. But you may be correct (even though you are pertending you are wrong) that it is desirable even when moving the mouse, as it would allow the program to highlight fine detail hit targets. This is useful in complex geometry to make it easier to pick things that are close together. Current programs either require the user to hold the mouse still for a split second to make sure the correct thing will be picked on click, or complex things like Maya typically draw their own manipulator to force sync.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">. Which is why (I assume) for moving<br>
windows the compositor does 100% of the work.</blockquote><div><br></div><div>The compositor is doing the window moving so that it can implement snapping. The client does not have sufficient information to do this.<br><br></div><div>I sure hope it is not because somebody said "Wayland is too slow to do this any other way". That would be really sad if the developers of Wayland thought that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Because if the<br>
application was involved there would be lagging movement whilst the<br>
application was switched out or doing something else.<br></blockquote><div><br></div><div>The application is involved already. Window dragging will not start until the application responds with the drag request.<br></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">
It does not work which is why no Window Managers ever do or should do this.<br></blockquote><div><br>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.<br><br></div><div><br></div></div></div></div></div>