*facepalm* On Wed, Jun 24, 2015 at 3:57 AM, Bill Spitzak <spit...@gmail.com> wrote: > 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".
Clients do not draw the mouse cursor, either the GPU (using hardware overlays) or the WM does. > >> >> So in your system the compositor would have to block mouse cursor >> movement until an application had dispatched and processed its events. >> Literally in this instance the user would be moving the physical mouse >> and nothing happening on screen > > > Yes, despite your attempt to be condescending, you are accurately describing > EXACTLY what I want! I was not being condescending... I am just not sure how you cannot see why this would not work? 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. There are plenty of other issues such as the application has to load or download something before it can render the next frame blocking the mouse causing jerkiness and lag. Even hiding the mouse can be irritating for users but not as irritating as the mouse not moving for 1-2s then suddenly appearing over the other side of the screen. >> >> It does not work which is why no Window Managers ever do or should do >> this. > > > 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. > > Maybe your computer is just underpowered so the WM drops fps? There should be no difference between when moving a window and not because the client is not involved directly. I state it again there are no window managers that block mouse movement waiting for a client. Take the example of window resizing as that is much easier to notice. OSX, Window, X11 and Wayland (Gnome Shell) do not sync the mouse with the new window size. 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. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
