

Wayland Architecture - alanhaggai
http://wayland.freedesktop.org/architecture.html

======
sedachv
This was posted before:

<http://news.ycombinator.com/item?id=1872536>

I flamed a lot. NETWORK TRANSPARENCY IS IMPORTANT. The effort put into Wayland
would be much better put into getting NX standardized as the next generation
of X protocol, and developing additional X extensions.

David Täht has some good perspective on X11 network transparency:

[http://the-edge.blogspot.com/2007/10/x11-is-dead-long-live-x...](http://the-
edge.blogspot.com/2007/10/x11-is-dead-long-live-x11.html)

~~~
wmf
Wayland can be network-transparent; this is so obvious that the developers
didn't bother to explain it (oops). Remote clients will connect to a local
proxy server that compresses the window updates (VNC-like) and sends them over
the network to a proxy client that decompresses into the appropriate buffers.
AFAIK none of this code has been written, but it's not impossible as some
people fear.

Now it may happen that no one cares enough about network transparency to
bother to write the code, but I don't see that as Wayland's problem.

~~~
praptak
Interesting quote by James Gosling (of NeWS fame, among others):

 _"I think that a more viable solution in the long run would be to replace the
X protocol with a very simple pixel copying protocol that uses the user-level
rendering libraries in the application to render to a local image buffer, then
copies the pixels over the net in something that looks vaguely like a video
stream.

There are a variety of compression hacks that make this surprisingly efficient
– this is essentially what the SunRay product does. Some analysis has been
done that shows that this uses essentially the same bandwidth as the X
protocol, if done well."_

From "Window System Design: If I had it to do over again in 2002."

~~~
mansr
This may work fine on a dedicated gigabit network, which is where SunRay
lives, but it does not work at all on a slow, possibly high-latency, link. To
see for yourself, try running any gtk or qt app over an ADSL link or even a
local wireless network, and enjoy the slide-show. Apps using server-side font
rendering, on the other hand, work nicely under these circumstances.

~~~
lmz
"A pixel copying protocol" would describe VNC and RDP as well, wouldn't it? By
running any GTK / Qt app over ADSL you mean running them using the X11
protocol?

------
wmf
To provide some context, Canonical and Red Hat are promoting Wayland as the
future of Linux graphics.

------
tl
Does this mean that if you prefer to not use compositing effects, that Wayland
is much ado about nothing?

~~~
mmastrac
Compositing isn't just about wobbly windows and other effects - it helps with
day-to-day use of the desktop by always painting every part of the window so
you don't end up with tearing/repainting artifacts as you drag stuff around
the window.

~~~
pmjordan
It also means apps don't receive as many redraw events. It's interesting how
priorities have inverted over the years: when windowed systems were first
developed, RAM was in short supply, so not storing invisible pixels was an
important optimisation, as was avoiding updates to pixels that hadn't changed,
as blitting involved the CPU and was super slow. Nowadays, RAM is plentiful
and blitting is essentially free, so we try to keep the number of updates
(which wake up the CPU and consume cycles and therefore [battery] power) to a
minimum.

~~~
ssp
_blitting is essentially free_

This is only true on discrete video cards that have local memory and lots of
bandwidth. Even there, the fill rate may be big, but it is still finite.

On integrated chips (~70% of the market by volume and rising) and on embedded
systems where the GPU and the CPU share the memory subsystem, blitting costs
memory bandwidth, and the GPU can't do it any faster than the CPU.

~~~
kelnos
Yep, exactly. Take nvidia Tegra2, for example. It's fine on small screens like
phones, but attach a large screen (or two) to it for a tablet, and your memory
bandwidth is the main limiting factor for doing redraws. If you clear the
entire screen on every frame, you max out under 25fps -- and that's _just_ to
clear the screen, and doesn't give you any time to spend to render anything.
Try and do anything interesting and you quickly drop below 10fps. So you end
up having to do a bunch of tricks to limit what you redraw. Forget full-screen
video with a high-res screen, though.

