The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 8:56 UTC (Fri) by renox (guest, #23785)
In reply to: The Wayland Situation: Facts About X vs. Wayland (Phoronix) by Fats
Parent article: The Wayland Situation: Facts About X vs. Wayland (Phoronix)

>When I last delved into this it was up to the clients to move their own windows

No, I made a similar mistake but this is wrong..
What happen is: when you click on the tittle-bar, the client recognize that you want to move its window and it asks the compositor to put the window in a "move mode": then when you move your mouse the compositor will move your window without the client being involved.
So 1) moving window will be smooth(done entirely server side) once the 'move mode' has started
2) if the client is busy then yes, you can't move its windows, but as the compositor ping continuously the clients, it can detect frozen window and "takeover" the window management.

Things are different for resizing where indeed you have the trade-off you describe, and as you said with Weston resizing is made by the client so every frame will be "perfect" BUT if the client is slow/busy then the resizing will be jerky/lagging (you move your pointer but the window doesn't resize until the client catch up).

IMHO this isn't very good here, like you, if a client is slow/busy I prefer that resizing its window has smooth resizing of the outline even if the content can become "ugly" (when the client fails to provide the content in time) to 'perfect frame' but with jerky/lagging.
Ideally we would use BeOS-like multithreaded clients which would never be slow/busy but in the meantime the trade-off is here..

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 14:25 UTC (Fri) by mjthayer (guest, #39183) [Link]

>>When I last delved into this it was up to the clients to move their own windows

>No, I made a similar mistake but this is wrong..
>What happen is: when you click on the tittle-bar, the client recognize that you want to move its window and it asks the compositor to put the window in a "move mode": then when you move your mouse the compositor will move your window without the client being involved.

I seem to recall hearing something about the client informing the window manager in advance about which areas of the window could be used for dragging, so that it would work even if the client was not responsive. I might be wrong though.

>IMHO this isn't very good here, like you, if a client is slow/busy I prefer that resizing its window has smooth resizing of the outline even if the content can become "ugly" (when the client fails to provide the content in time) to 'perfect frame' but with jerky/lagging.

I have to say that I actually prefer resizing to be the client's business, having seen enough cases of the window manager and client mis-co-ordinating that. In extreme cases the window manager could still clip the client.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:56 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

as the compositor ping continuously the clients

Isn't that rather bad for power management?

One hopes that it actually pings clients which should have an event directed to them when such an event turns up, which would add no overhead and have the same effect of detecting slow or unresponsive clients reasonably rapidly.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 12:43 UTC (Tue) by renox (guest, #23785) [Link] (1 responses)

Weston being a prototype, I'm not sure that they worried about power management in their implementation especially as the protocol is the same in both cases.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 13:09 UTC (Tue) by nix (subscriber, #2304) [Link]

Yeah, that's what I expected. Of course prototypes turn into production implementations all the time :P

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 19, 2013 0:24 UTC (Wed) by daniels (subscriber, #16193) [Link] (1 responses)

> One hopes that it actually pings clients which should have an event directed to them when such an event turns up, which would add no overhead and have the same effect of detecting slow or unresponsive clients reasonably rapidly.

It does.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 25, 2013 20:37 UTC (Tue) by nix (subscriber, #2304) [Link]

Good design, then. Unlike certain other programs I could mention (yes, mongodb, of *course* you should wake up a hundred times a second when idle because select() is too hard to use properly, sigh.)