Linked by Thom Holwerda on Mon 13th Feb 2012 23:44 UTC
X11, Window Managers "Although current discussion of the Linux desktop tends to focus on the disharmony around Unity and the GNOME shell, the true revolution on the desktop is taking place out of sight of users. The Wayland display server is expected to reach version 1.0 later this year, and is seen by many as the long term replacement for the X Window System, with real potential to improve and transform the performance of the desktop for Linux users."
Thread beginning with comment 507068
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Wayland does not "replace" X
by renox on Tue 14th Feb 2012 09:30 UTC in reply to "RE: Wayland does not "replace" X"
renox
Member since:
2005-07-06

From my own reading on Wayland, X isn't being kept for remoting - it's being kept for compatibility

I have my doubts: the desktop projects (KDE, Gnome) which do a lot of maintenance of the toolkits are quite famous for their lack of compatibility.

So I wouldn't be surprised that soon they'll say, now we don't support anymore X, Wayland is better..

And IMHO noone has suggested a convincing remote mechanism for WAN access on Wayland (no rewrite everything in HTML isn't convincing, neither is send full buffers).

Reply Parent Score: 1

Gusar Member since:
2010-07-16

I have my doubts: the desktop projects (KDE, Gnome) which do a lot of maintenance of the toolkits are quite famous for their lack of compatibility.

So I wouldn't be surprised that soon they'll say, now we don't support anymore X, Wayland is better..

That's not what's meant here with "compatibility". What's meant here is legacy apps for which there is no current equivalent, but they still do their job fine. X will be there, working inside Wayland, so that you'll still be able to run such legacy apps.

Reply Parent Score: 3

Vanders Member since:
2005-07-06

And IMHO noone has suggested a convincing remote mechanism for WAN access on Wayland (no rewrite everything in HTML isn't convincing, neither is send full buffers).

Why would you expect the client to send the full compositing buffer? It just has to send the damage regions (and probably it's clip list).

Reply Parent Score: 3

siride Member since:
2006-01-02

That's still a slow way to do it. RDP supports tunneling GDI and GDI+ commands over the wire so that rendering can be done server-side. Images, of course, will have to be transmitted over the wire, but text and rectangles and even gradients can be done server-side. The result is that RDP is pretty darn fast, especially compared to the Unix equivalents (VNC, which uses screen-scraping and is slow; NX which is closer to tunneling and thus is faster, but still not as good as RDP; native X which uses nothing but X commands, but because of the inefficiency in protocol usage, is horribly slow over the internet).

Reply Parent Score: 3