[cbs]

From what I understand, modern X applications run remotely are just painting a region of bytes to be shot over the wire anyway. I'll borrow X terminology for a second here, what functional difference is there between these two approaches:

X client -> (network) -> X server

Wayland "client" -> wayland intermediary "server" -> (network) -> wayland intermediary "client" - wayland server

I get the feeling that the pushback (not necessarily yours, but in general) might be rooted in the visual interface where an X server will manage and composite remote applications as if they were local but vnc and rdp (in most use cases) offer a window to the remote system. As I understand it, the former presentation style isn't precluded by wayland's approach.

Wayland's design for a client and server on the same machine doesn't do much more than pushing a buffer full of painted bytes to the server. So anything fancier than that isn't something they refuse to implement for just a network connection, they don't do it at all.

[belorn]

> From what I understand, modern X applications run remotely are just painting a region of bytes to be shot over the wire anyway.

No, that's incorrect. X server sends high level commands over the network and let the client render the requests. VNC on other hand work exactly as you describe, by simply copying the servers image buffer (a region of bytes), compresses it, and sends it over to be painted on the client's screen.

My general approval of X method rather then the VNC approach mostly comes down to performance (less traffic, smother rendering) and style. Its the same reason why I like the concepts of vector graphic over pixel formats.

But if Wayland is designed to not have any high level commands (like "create a window"), and thus only push buffers of pixels between server and client, I guess that is that then. Anything beyond copying the image buffer would then be in conflict with Waylands core design.

[fmoralesc]

> X server sends high level commands over the network and let the client render the requests.

AFAIK, that's not true most of the time nowadays, since most toolkits don't use X drawing primitives.

[lazyjones]

The X way of doing window updates became impractical with common graphics-heavy applications like web browsers. I could already feel this in the mid-90's when opening a browser window on a 19" NCD X-Terminal took several seconds over 10mbit/s Ethernet (noticeable because most other X client applications at that time used drawing primitives and appeared instantly).

For modern applications (graphics- and video-heavy), VNC/RFB seems like a much more suitable protocol, although I haven't really kept up with the latest X extensions that probably cover some of these applications.

Personally, I liked the X architecture more (despite X's inherent complexity) and expected it to become more popular with cloud-hosted applications etc., but as applications and GUI toolkits evolved in an unsuitable way (i.e. not using X's primitives), it's probably time to let go. Or to build a proper GUI toolkit first...

[dllthomas]

It works like this:

User -> Interface -> X Server -> Network -> X Client

The huge functional difference (in terms of what you describe - no idea if that's how Wayland intermediary whatever will actually work) is that with X you do not need an X server running or even configured or even installed on the system the client application is running on - only on the system it is displaying to. This may or may not be significant, depending on how lightweight and portable and easily (and flexibly) configurable the Wayland server winds up being.