Wayland Preparing For 1.0 Stable Release

[smitty3268]

Not to mention we run in a mixed environment of Linux (clients) and Solaris (file servers)... and there are no plans for Wayland on Solaris, which means we're relying on X one way or another.

Now I'm especially confused on why you are concerned here. If you have to keep Solaris support, then obviously you have to stick with X no matter what. So nothing about Wayland will affect you at all. X can run on top of Wayland just fine - in fact I remember running remote apps over X on a windows machine back in college, and that worked just fine too. Wayland will obviously integrate much more closely with X than that or OSX.

So congratulations to Mr. Shuttleworth with his fancy global menus and cool compiz effects. I really do like them on my home PC.

What does that have to do with Wayland? You seem to have some funny ideas about what it's about.

So if something similar (i.e., not pixel-scraping garbage) can be made to work in the Wayland context... fantastic! I can't wait to sign up. If not... then I wish everyone good luck with their toy display server.

I don't think i can count the number of times people have explained how that will work to you.

This, of course, all presupposes that the binary drivers can be made to work with Wayland. Without that this project is dead on arrival.

Binary driver support will be vastly simpler than with X. Instead of those drivers having to replace 90% of X with their own code, they can get by with just writing a simple interface to share their buffers with Wayland.

[daniels]

It seems like the problem here is that the basic answer to network transparency in Wayland is "that should happen in a different layer where Wayland doesn't play" (which is a completely legitimate design decision for Wayland), but it tends to come off more like "yay web apps, and legacy apps can just do all local rendering all the time and constantly sling boatloads of dumb buffers around the network; problem solved" (which is stupid).

So, you guys do all realise that this is what basically every X app does already today, right? Unless you're running Motif/Xaw/Xt apps which actually use core X rendering, of course. GTK+, Qt, EFL and friends all composite one massive image for the window on the client side, and then upload this image to the server. The only X rendering operation you'll see in common usage today is PutImage and Composite, basically.

Even better, since X performs absolutely no compression whatsoever, it's actually the most inefficient method of doing a network-transparent window system you could get, without going out of your way to insert random junk into the data stream. So if Wayland's solution is a screen-scrape and compression, which I expect it will be, then it'll be a hell of a lot _more_ efficient than X.

Anyway, carry on ...

[kraftman]

Not to mention we run in a mixed environment of Linux (clients) and Solaris (file servers)... and there are no plans for Wayland on Solaris, which means we're relying on X one way or another.

Then switch to Linux. I didn't see anything from solaris given to FLOSS lately. Why would someone care about that closed crap?

[elanthis]

Even better, since X performs absolutely no compression whatsoever, it's actually the most inefficient method of doing a network-transparent window system you could get, without going out of your way to insert random junk into the data stream. So if Wayland's solution is a screen-scrape and compression, which I expect it will be, then it'll be a hell of a lot _more_ efficient than X.

Silly X developer, thinking that the average Web forum Linux fanboy has any remote knowledge of how the software they evangelize about even works, or has the capacity to understand it.

[smitty3268]

Silly X developer, thinking that the average Web forum Linux fanboy has any remote knowledge of how the software they evangelize about even works, or has the capacity to understand it.

It sounds like he must be some Ubuntu-tard who only cares about gee-whiz effects and has no experience with the reality of how important X is to the the fortune 500 companies out there.

Or something like that.

[johnc]

Silly X developer, thinking that the average Web forum Linux fanboy has any remote knowledge of how the software they evangelize about even works, or has the capacity to understand it.

Not really. Compression is nice for networks that have limited bandwidth and also have the computing horsepower to handle the extra load. (And by "nice" I mean "adds latency".) Where bandwidth isn't an issue you really wouldn't want to compress it.

[phred14]

Why do you keep concentrating on vnc? Ajax SPECIFICALLY said the actual method is determined by Wayland. You can use a vnc-like protocol, OR something like rdp/spice. For spice, as long as both sides have the spice support, you can grab the window pre-render and send it over as a series instructions to be handled by the client. This work isn't yet WAN ready, but it will be by the time you'd need it.

I was talking about how I handle remote graphics today, and vnc is part of that mix. Really it's a matter of setup time vs performance. Running x11vnc there plus vncviewer here takes the least setup time and has the poorest performance. But if you're only in for a few minutes, it's the best option. Setting up to run everything locally takes the longest time, but usually gives the best performance. If you're in for a day, it's the best option.

It's sounding more like Wayland will at least have some set of options to cover my needs. It's worth realizing that it's not just one method, but a range of options with different characteristics. Choose the best fit.

[phred14]

So, you guys do all realise that this is what basically every X app does already today, right? Unless you're running Motif/Xaw/Xt apps which actually use core X rendering, of course. GTK+, Qt, EFL and friends all composite one massive image for the window on the client side, and then upload this image to the server. The only X rendering operation you'll see in common usage today is PutImage and Composite, basically.

Even better, since X performs absolutely no compression whatsoever, it's actually the most inefficient method of doing a network-transparent window system you could get, without going out of your way to insert random junk into the data stream. So if Wayland's solution is a screen-scrape and compression, which I expect it will be, then it'll be a hell of a lot _more_ efficient than X.

Anyway, carry on ...

I remember reading long-ago discussions on lbx and dxpc, and by now have blurred the two together, forgive me please. ISTR that they split the X datastream into 4 categories, and treated each category differently. There were combinations of compression, caching, state-mapping, and out-and-out short-circuiting. They described the X protocol as very verbose, with frequent conversations about current state. By keeping a state map they were able to only send hints over the wire, and pretty much eliminated that section of the traffic. I believe fonts and other stuff like that were both compressed and cached, and bitmaps and such were compressed. It was quite a while ago, so the memories are a bit vague.

But the net I took out of it was that some parts of the X protocol could be just plain more efficiently designed.

Second point/question... When using X tunneling through SSH, they offer compression. Back in the day, it didn't seem that that compression would be anywhere near as effective as dxpc. If as you say, most of what's flowing through X now is bitmaps, etc, perhaps SSH compression with modern toolkits is a better bargain than it used to be.