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

Posted Jun 13, 2013 19:25 UTC (Thu) by Fats (guest, #14882)
Parent article: The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Next to network transparency that should/could be better on Wayland but without a commitment of implementing it I have another big worry.
When I last delved into this it was up to the clients to move their own windows, minimize/maximize them, etc. So when the client is busy with something else you can't move it's windows. Let me tell you this is one the Windows 'features' I hated most. Is this fixed in the mean time for Wayland ?
Maybe this is needed for this having the 'display right all the time'. But if I have to choose between windows movable at all times or flicker/lag free display at all time, I'll choose movable at all times without a wink.

(Log in to post comments)

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

Posted Jun 14, 2013 6:36 UTC (Fri) by micka (subscriber, #38720) [Link]

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

If I remember correctly, it's a choice that's made at the compositor level. For example, I think that for Kwin (the compositor), window management will not be done by the client.

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

Posted Jun 14, 2013 8:56 UTC (Fri) by renox (guest, #23785) [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.
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]

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]

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]

> 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.)