The Wayland Situation: Facts About X vs. Wayland

[Jonimus]

While I understand that Wayland does do many things right there are 2 things I still don't fully understand about wayland.

Will something like ssh -X be possible with wayland and is anyone looking into it. I mean stupid simple remoting the way X has supported it for years. Sure its broken for DRI2 clients but most day to day programs don't need GL acceleration, Browsers supporting WebGL being the one exception but browsers over ssh -X was pretty broken already, I should still be able to run a graphical text editor or file manager over the network. I don't care if it is just sending images, I can deal with that, but it must be as stupid simple as it is now for it to be as awesome.

How is multi Display a "Client side issue" supposed to be workable? WHen you say client side, is that a window manager or does that mean every program has to care about which display they are being output on? This seems like a glaring issue and I am just wondering what the plans are here. As someone who almost never works on a machine with less than two displays, how gracefully that is handled is a major issue to me and it seems like xrandr 1.3/4 handle that rather awesomely, especially once that library that I can't remember the name of at the moment that remembers Display layout based on EDID.

On a related note, with the multi-display handling will it be possible to have overlapped displays, this is one thing that Quartz and X allow that Windows doesn't allow and I use often.

[pjezek]

Args?

There is nothing that precludes lightweight WMs. I think a simple compositor with hooks for a WM would be nice, but I haven't actually done any development with it, only browsed the source.

Wayland is a nice, simple protocol and can easily outperform X, simply due to the decreased overhead.

I see a clear propaganda and no professional arguments. Any other wayland priests or real developers' opinions? Where you go, phoronix auditorium...

[bwat47]

1) I have noticed Wayland is not supporting simple WMs like *Box, PekWM, Windowmaker etc. Any fresh info?

2) How can survive light distros like Crunchbang or Archbang with Wayland as an only display server without X?

3) What would be productivity gains with Wayland/DE in comparison with WM/X?

Btw, in my opinion X can fill the task with very limited modules and with very low Xserver activity compared to wayland...

There is nothing about wayland that "does not support" simple window managers, where on earth are you pulling that claim from?

[johnc]

Wayland is a nice, simple protocol and can easily outperform X, simply due to the decreased overhead.

We have benchmarks already?

[brosis]

Using this forum page as an example:

http://tinypic.com/r/34ytse9/5

http://tinypic.com/r/avr7nk/5

The background without text compressed to 8.7kb, the background with text compressed to 87kb.
The text in this image took 2.3kb uncompressed, 1.2kb compressed with gzip.

Sending the plain background + text takes only 11% of the space, resulting in better latency and so usability.

What you are still missing, IMHO, is the point I mentioned before, that data array is much easier to SIMD and process than individual calls.

My opinion, is that for single text with background, there are not only transfer rates, there is also CPU cost on both sides. Think of drawing overhead, think of antialiasing, think of shading etc. IMHO data array approach it will quickly balance out, because good array compression algorithms work exactly like MPEG and send only b-frames(diff of data). From this point, the network bandwidth cost for using calls is nearly identical to data array; bigger changes on screen - more data,.. but also more calls. However, the data array approach is more controllable for thin-clients in terms of load, we can implement some protocols regarding frame drops, compress quality; we can maintain responsiveness this way. There is no easy way to "z-buffer" the calls....

For data array method, the local thin client will only need to keep decoding (the known codec) and blitting fast enough.
For call method, the local thin client will have to be able to do a wide array of things...

In my opinion this is why Wayland is more network efficient than X. I think Wayland will outperform X on CPU efficiency, network efficiency and processing requirements for thin clients. Also, I think that today to focus on local loop (desktop) with network support is better, than focus on network-transparent loop at sacrifice of local(desktop) features(responsiveness etc); because modern hardware is more than capable to render incoming buffers, or draw them on its own. No need to draw interface via lines and text...

Then again, think about windows 3.0 and how everything froze, when an application forgot to release DC context. This is exactly same with Xorg, and no more with Wayland (because each application has its own sandbox, and its it's own responsibility to keep it tidy).

[garegin]

There's so much wrong here.

First of all, WDM is the Windows Driver Model, and it was dropped when Windows Vista was released. The driver API in Windows Vista is called the Windows Driver Foundation, and the display driver portion of that is called the Windows Display Driver Model (WDDM), which is perhaps what you're thinking of.

These don't affect desktop applications much at all. This would be like updating your video driver in Linux; no desktop software needs to be changed.

When it comes to the display server, on Windows you still use the old Win32 API, which hasn't changed in nearly two decades. Changing from X to Wayland is much more similar to changing from Win32 to WinRT - the new library for Metro apps on Windows 8. To use WinRT, you need to rewrite your software, and Metro runs as a separate app on top of Win32. This is a lot like running Wayland on X.

You might also be thinking of UAC (User Account Control), which was added in Vista and is what makes Windows dim the screen and do sudo-style account elevation. This does affect desktop apps, because in modern Windows you can no longer write to the Program Files directory, but most of the time this still works, because Windows has an emulation layer that redirects output to a different folder.

Finally, you must remember the Vista launch differently than me, because I remember a lot of problems with Vista at launch time!

I'm talking about the http://en.wikipedia.org/wiki/Desktop_Window_Manager. And yet applications from before that weren't designed with DWM in mind still can work (some don't obviously), whereas in linux you have to port your application to a toolkit that supports wayland.

[tvall]

compiled wayland/weston and have it running on debian now. on my core2duo it is much smoother than lxde.

there is only thing that could possibly keep me from switching, openarena and minecraft running under xwayland cant grab the cursor properly. any simple workaround?

chromium, eclipse, and wayland-terminal all work perfectly fine, so the only thing i would miss from switching at this point is random fragging and minecraft.

when will we see a working bsd port?

[Akka]

As I understanded Martins new blog. KDE SC 4.11 Beta 1 realesed next week is suposed to have a experimental wayland backend.

http://blog.martin-graesslin.com/blog/2013/06/starting-a-full-kde-plasma-session-in-wayland/

[curaga]

What you are still missing, IMHO, is the point I mentioned before, that data array is much easier to SIMD and process than individual calls.

My opinion, is that for single text with background, there are not only transfer rates, there is also CPU cost on both sides. Think of drawing overhead, think of antialiasing, think of shading etc. IMHO data array approach it will quickly balance out, because good array compression algorithms work exactly like MPEG and send only b-frames(diff of data). From this point, the network bandwidth cost for using calls is nearly identical to data array; bigger changes on screen - more data,.. but also more calls. However, the data array approach is more controllable for thin-clients in terms of load, we can implement some protocols regarding frame drops, compress quality; we can maintain responsiveness this way. There is no easy way to "z-buffer" the calls....

You're missing that remoting should always be lossless. Text, especially colored text, suffers badly with the common video compression artifacts. Any artifact is unacceptable.

We can assume any thin client has a 2d-capable GPU, to handle the blending of the text on the image. The CPU overhead of rendering text is very small, easily doable on any thin client released in the last 15 years, or phone for the last 10.

[curaga]

Obviously having a single image is faster, as you say; but the hardware already handles X well, which has more overhead than either of the models discussed here.