Wayland 1.0 Stable Release Is Imminent

[daniels]

Half of those things aren't X's faults. It's quite unfair to blame it for problems in something else.

They really are tho. Especially during resize, the app → X server → window manager → X server → app → X server dance for resizing makes that a disaster: merging the WM/compositor into the display server and introducing client-side decorations directly fixes that. As for tearing, juddering animations, etc, they can mostly kinda be fixed, but only by adding still more three-way handshakes between the app, the X server and the WM. That's your 95% solution for judder-free and tear-free animations, at the cost of several hojillion context switches per second. The other 5% is totally unfixable due to the nature of X.

X is wildly, wildly inappropriate for modern toolkits. It does kinda-sorta work, but we're (ab)using it in a way that's totally contrary to what it was designed for, and it really shows.

[daniels]

In terms of production environment, Wayland isn't used anywhere yet, so yes, it's pretty much a research project right now. With potential to become the next standard, yes. But we're a long way off from that.

It has actually seen some deployments in closed/embedded systems ...

[renox]

Wishful thinking..

They really are tho. Especially during resize, the app → X server → window manager → X server → app → X server dance for resizing makes that a disaster: merging the WM/compositor into the display server and introducing client-side decorations directly fixes that.

Fix it? With Weston, when you click on a window to resize/move it, the click event is sent to the application which then decides whether it is a resize or move action and send the corresponding command to Weston. So if the application is slow for whatever reason the moves/resizing will be jerky/laggy..
I wouldn't call this a fix, it's a trade-off!

[daniels]

Fix it? With Weston, when you click on a window to resize/move it, the click event is sent to the application which then decides whether it is a resize or move action and send the corresponding command to Weston. So if the application is slow for whatever reason the moves/resizing will be jerky/laggy..
I wouldn't call this a fix, it's a trade-off!

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.

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

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

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.

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

[smitty3268]

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

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.

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

If you watch the Wayland demo, they show handling an app that is stalled. Clicking/dragging anywhere on the window to move it around. Wayland detects when the app is no longer responding, and can provide custom behaviours for that case, which would allow popping up a menu, or shrinking/expanding the window size if that is what you want to do.

[renox]

If you watch the Wayland demo, they show handling an app that is stalled.

I am NOT talking about an application which is stalled, just an application which is slow to handle events.
Resizing/moving such application with client side management of decoration (Weston) will feel slow/jerky,
but it wouldn't with server side management of decoration even though the content of a window could become a little garbled when resizing.

[zxy_thf]

If you watch the Wayland demo, they show handling an app that is stalled. Clicking/dragging anywhere on the window to move it around. Wayland detects when the app is no longer responding, and can provide custom behaviours for that case, which would allow popping up a menu, or shrinking/expanding the window size if that is what you want to do.

Furthermore, a composer can even use custom content instead of the frozen one.
As the composer can do anything in composing a frame, the client side decoration won't be a problem.

[makomk]

According to the people who are working on Wayland the compositing causes very little overhead and it's covered in almost every presentation that I have seen. The problem with X.org compositing is also often highlighted. Benchmarking could be a bit difficult with the same software that Phoronix uses due to fact that there are changes in many parts of the system like moving from GLX to EGL that still has performance problems. If you are interested about Wayland you could of course start by watching the talk on this very article...

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.

[Ancurio]

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.

"Wayland's OpenGL support"? Do you have any idea what you're talking about?