"Not now" vs "No"

Posted Feb 14, 2012 16:33 UTC (Tue) by CChittleborough (subscriber, #60775)
In reply to: There's some irony here... by daglwn
Parent article: Wayland - Beyond X (The H)

The question has been and continues to be, "will we bother to implement network transparency?" It seems so far the only answer ever given is, "no."

Actually, Kristian Høgsberg, Adam "Ajax" Jackson and others have all written about ways to provide network transparency in the future. For the present, the Wayland/Weston developers are concentrating on getting the protocol right and providing a first implementation.

Once this is done, they plan to produce a production-quality X-server-as-a-Wayland-client, AFAICT. (They've already demo'd X-on-Wayland, but ISTR that those were not production-quality.)

In the longer term, we already have proof-of-concept implementations of network-transparency in the form of VNC, Spice, Xpra, etc. These use various approaches; the "Remote Wayland" project would need to select an approach, design a network protocol and write some non-trivial software, which will take some time, but success is basically guaranteed if vendors provide enough resources.

to post comments

"Not now" vs "No"

Posted Feb 14, 2012 17:35 UTC (Tue) by daglwn (guest, #65432) [Link] (8 responses)

> Wayland/Weston developers are concentrating on getting the protocol right

How can they be sure the protocol is right if they don't consider network transparency from the start?

I'm fine with alternate solutions as long as they perform as well or better than remote X and are as easy to use (ssh -X). I'm doubtful that will happen if it's not designed in from the start.

"Not now" vs "No"

Posted Feb 14, 2012 20:59 UTC (Tue) by wmf (guest, #33791) [Link] (1 responses)

They have considered it; they just haven't implemented it. (There is a concern that nobody will provide funding and it will never get implemented.)

"Not now" vs "No"

Posted Feb 15, 2012 1:32 UTC (Wed) by daglwn (guest, #65432) [Link]

That's exactly the problem.

Network transparency will need a second protocol

Posted Feb 15, 2012 9:14 UTC (Wed) by CChittleborough (subscriber, #60775) [Link] (5 responses)

I should have made myself clear; sorry. In the sentence daglwn quoted, I meant the non-networked protocol for use between apps and Wayland servers running on the same system. That protocol involves sharing graphics buffers via the kernel, so it can never be network-transparent. The devs have released 1.0, so they must think they've got that protocol about right.

Network transparency will require a second protocol which sends some kind of image deltas from the app to the server. Choosing how to do those deltas will take some time, but should pose no insurmountable challenges.

Network transparency will need a second protocol

Posted Feb 17, 2012 10:09 UTC (Fri) by jezuch (subscriber, #52988) [Link] (4 responses)

> Network transparency will require a second protocol which sends some kind of image deltas from the app to the server. Choosing how to do those deltas will take some time, but should pose no insurmountable challenges.

My impression was that the Wayland protocol is already all about deltas: applications update the buffer and tell Wayland what changed (i.e. what it the delta). Pushing those via network seems trivial. Is my impression wrong?

Network transparency will need a second protocol

Posted Feb 17, 2012 12:24 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

Devil is in details. Some trivial (and fast in local case!) effects (think fade-ins when you try to pull list on Android beyond it's limit) can generate literally tons of update messages. And this is exactly the type of effects which Wayland is suposed to make sensible!

Network transparency will need a second protocol

Posted Feb 24, 2012 16:17 UTC (Fri) by wookey (guest, #5501) [Link]

'literally tons'.

I never realised messages had so much mass. How come the handset doesn't get really heavy after a while - does the excess weight get sent to the base-station posts where it can disspate harmlessly?

Local Wayland protocol does not use deltas

Posted Feb 18, 2012 11:25 UTC (Sat) by CChittleborough (subscriber, #60775) [Link] (1 responses)

The Wayland protocol does not use deltas. The server (=compositor) maintains a graphics buffer and gets the graphics hardware to display it. When a client wishes to change the display (eg., because of user input), it renders into its own graphics buffer (=window) and then tells the server (=compositor) about the damage region(s). The server can then update the visible graphics buffer. The aim is that the visible buffer is always what you would get if you composited the client buffers according to window position etc, but the server only processes the parts of client buffers that have changed.

Local Wayland protocol does not use deltas

Posted Feb 20, 2012 11:24 UTC (Mon) by etienne (guest, #25256) [Link]

Is that the case that so much eye-candy has been added to the desktop (xterm with transparent background,...) that remote desktop cannot handle that amount of display primitives, and the system has to deal with bitmap only, sampled after the visual effect are finished?
It seems that, on a very high latency network, we may want simple display primitives, and use font, graphic, buttons, mouse shape, background locally stored (when their UUID is available locally)...