Originally posted by phred14
View Post
Announcement
Collapse
No announcement yet.
Wayland Preparing For 1.0 Stable Release
Collapse
X
-
-
Originally posted by johnc View PostNot 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.
So congratulations to Mr. Shuttleworth with his fancy global menus and cool compiz effects. I really do like them on my home PC.
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.
This, of course, all presupposes that the binary drivers can be made to work with Wayland. Without that this project is dead on arrival.
Comment
-
Originally posted by Ex-Cyber View PostIt 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).
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 ...
Comment
-
Originally posted by johnc View PostNot 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.
Comment
-
Originally posted by daniels View PostEven 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.
Comment
-
Originally posted by elanthis View PostSilly 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.
Or something like that.
Comment
-
Originally posted by elanthis View PostSilly 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.
Comment
-
Originally posted by liam View PostWhy 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.
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.
Comment
-
Originally posted by daniels View PostSo, 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 ...
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.
Comment
Comment