Wayland 1.0 Stable Release Is Imminent

[Jam66es]

it seems to have a lot of goodwill with many important developers in the Free Desktop ecosystem

[vertexSymphony]

In other words, we don't actually have any benchmarks to show that Wayland compositing is actually low-overhead, and even if we did it wouldn't matter since Wayland's OpenGL support is incapable of running most games.

So much opinology, lol ... lot's of people here just want to argue for the sake of it, even if they don't have a pale idea about the subject x')

[smitty3268]

I am NOT talking about an application which is stalled, just an application which is slow to handle events.

There's no difference.

Wayland sees that an app is stalled, by checking to see if it responds to events quickly. If it fails, the compositor can take over.

Checking that event handling is probably just as fast as going through the whole X chain, and then hoping that X or the window manager isn't slow to respond itself.

In other words, we don't actually have any benchmarks to show that Wayland compositing is actually low-overhead, and even if we did it wouldn't matter since Wayland's OpenGL support is incapable of running most games.

LOL, FAIL.

[renox]

Not so sure!

There's no difference.

Wayland sees that an app is stalled, by checking to see if it responds to events quickly. If it fails, the compositor can take over.

In theory there is no difference, in practice there is: an application slow to handle event can be slow enough that moving window feels jerky/laggy but fast enough that the compositor won't take over.
I doubt that the timers for the compositor are small otherwise it'll keep showing "busy" application which is annoying for users, but an user moving a window will see a delay if the application pause more than 1/60s!

The ironic part is that moving a stalled window can be smoother than moving a "normal" window because moving a stalled window can be done fully in the server whereas with Weston moving a normal window needs a roundtrip.

[smitty3268]

In theory an application slow to handle event can be slow enough that moving window feels jerky/laggy but fast enough that the compositor won't take over.
I doubt that the timers for the compositor are small otherwise it'll keep showing "busy" application which is annoying for users, but an user moving a window will see a delay if the application pause more than 1/60s!

Maybe, maybe not. I imagine wayland pings the app right when you click on the window. I don't think it should require any more than 1/60s to get a response.

[daniels]

I totally disagree: I prefer responsiveness over prettiness.
When there is a separated window manager, if the application becomes busy, you can still draw the window outlines so the resizing still feel responsive (even if the content of the window becomes ugly),
, with Weston this won't be the case, the window will freeze resizing until the application answer again..

Weston is perfectly capable of doing outline resizes, and I'm not sure why you think it isn't.

The only way to have both is to ensure that the application is never busy by using multithreading, very,very nice when you have it but a big change.

Still doesn't help if the app's waiting on I/O because everything got paged out.

And what about moving windows?
Here, client side management of decorations looks even worse compared to server side management of decoration (except when the application is multithreaded)!

How? Again, it's more fluid because the compositor moves the window directly and doesn't even need to tell the application ever. With X11, the pointer event goes to the window manager, which then tells the server where to move the window. Removing the round trip can only help.

But there's no difference in client vs. WM decorations here at all, because the decorations are never relayouted or redrawn.

[renox]

Weston is perfectly capable of doing outline resizes, and I'm not sure why you think it isn't.

I didn't say that Weston isn't capable of doing it, but as it is the application which decides that the mouseclick is a resize/move event (client side window decoration management), if the application is slow to answer then Weston cannot do anything until it decides that the application is stalled and then takeover.

Still doesn't help if the app's waiting on I/O because everything got paged out.

True, an additional drawback of having window management partially handled by the applications: as a window manager is used by all the applications it is less likely to be "paged out" and it could be locked into memory for distribution which wants to maximize responsiveness (difficult though as one must ensure that it use only a small amount of memory).

How? Again, it's more fluid because the compositor moves the window directly and doesn't even need to tell the application ever.

Wrong, with Weston it is the application which converts mouse clicks to 'move action' (client side decoration management) so the application is in the loop.

With X11, the pointer event goes to the window manager, which then tells the server where to move the window. Removing the round trip can only help.

Note that with remote display, the window manager is in the same station as the display server whereas the application isn't so the RTT is very different.
With server side window management (which Weston doesn't do normally i.e. unless it decides that the application is stalled), the application doesn't need to be the loop when it is moved, whether it is best to have the window manager
in the display server process or in a separated process is a different implementation issue.

But there's no difference in client vs. WM decorations here at all, because the decorations are never relayouted or redrawn.

This is not about drawing this is about RTT and event management, with server side window management you have much smaller RTT and the events are handled by code dedicated only to window management not by applications which do already many other things..

[Marc55Mo]

Wayland is and has been for a long time developed by Intel and Collabora among other companies commercially.

[renox]

It's not 100%, since there is no acceptable solution to 'my app doesn't respond quickly to resize requests', but vastly better than before.

The Wayland model is that the app tells the compositor to initiate a resize sequence, at which point the compositor just starts feeding the app resize events as appropriate. The then app sends the window with decorations already drawn, which is always safe to draw on screen. We've cut out a huge amount of the round trips and lag inherent in the X11 model, where the server would send a pointer update to the client, who would request a resize from the server, which would ask the WM what it thought; the WM would then paint a new frame and resize both its frame window and the real client window; the server notifies the app of a resize, at which point the app can finally draw its content. I left out all the app -> X server -> WM -> X server -> app roundtrips for synchronisation through window properties too - it looks even worse if you add those in.

So yeah, I maintain that the problem's solved as well as it could be.

And you're right, sorry for my mistake I thought that 'client side decoration' meant that each time the interpretation of every mouse clicks was sent to the client even when moving a window which isn't the case apparently, the client initiate a 'move grab' sequence and then the server can do the work alone, nice!
Ooops, either I misread the documentation or there is a need of better documentation..