The Wayland Situation: Facts About X vs. Wayland

[renox]

Xft draws text client-side into a picture, which is then blitted via the XRender API - the text itself is not sent over the wire to the display server, just images.

And these images of the individual character are cached and reused which means that it much more bandwith efficient than Wayland..

[mrugiero]

And these images of the individual character are cached and reused which means that it much more bandwith efficient than Wayland..

I don't think the use of Wayland gets in the way of a similar implementation. AFAIK, Wayland only does the buffer management. If desktop people feel the need, they can do a common drawing API, at the depth they feel convenient, and send the commands over the network, and they can tell Wayland locally how to modify the surface and how to composite it. It will probably introduce a slight overhead relative to having a monolithic solution, but I believe the advantage for the general uses outweights this small loss. And what I'm suggesting isn't that crazy, ICCCM born by a similar itch caused by X, but for communication between clients.

[renox]

I don't think the use of Wayland gets in the way of a similar implementation. AFAIK, Wayland only does the buffer management. If desktop people feel the need, they can do a common drawing API, at the depth they feel convenient, and send the commands over the network, and they can tell Wayland locally how to modify the surface and how to composite it.

No Wayland doesn't prevent this but as it doesn't provide this:
1) this is the reason why it cannot be named X12
2) by not providing this, they probably delayed such kind of solution for several years, perhaps forever and we'll be stuck with sending 'big' (inefficient) buffers. Those who say "use X then" forget that toolkits will probably dump X as soon as they can (5 years perhaps?): toolkits have a poor history of backward compatibility!!

[dee.]

No Wayland doesn't prevent this but as it doesn't provide this:
1) this is the reason why it cannot be named X12
2) by not providing this, they probably delayed such kind of solution for several years, perhaps forever and we'll be stuck with sending 'big' (inefficient) buffers. Those who say "use X then" forget that toolkits will probably dump X as soon as they can (5 years perhaps?): toolkits have a poor history of backward compatibility!!

1) even if you had your drawing API, no app would use it, they'd just do just like they do now, bypass it and draw directly. And you'd be back to square one.
2) which is because, the reasons that software wants to render directly are still there and aren't going to disappear even if you make X12, X13, etc.
3) bandwidth is getting cheaper and more ubiquitous, we can already stream HD video through the internet so what actually is the problem?

[renox]

1) even if you had your drawing API, no app would use it, they'd just do just like they do now, bypass it and draw directly. And you'd be back to square one.
2) which is because, the reasons that software wants to render directly are still there and aren't going to disappear even if you make X12, X13, etc.

This is not 100% true you can configure Qt to use XRender for example.

3) bandwidth is getting cheaper and more ubiquitous, we can already stream HD video through the internet so what actually is the problem?

HD video use compressed delta images: here you are streaming full uncompressed image, it's even worse in bandwith, especially when everyone will have "retina-display" monitors!
Yes, you can compress the buffers but it adds latency which is *bad*, sending text from the application to the display server use much less bandwith so you don't need compression so less latency (or less compression plus compressing the background independently of the text would give much better compression) .

[giselher]

This is not 100% true you can configure Qt to use XRender for example.


HD video use compressed delta images: here you are streaming full uncompressed image, it's even worse in bandwith, especially when everyone will have "retina-display" monitors!
Yes, you can compress the buffers but it adds latency which is *bad*, sending text from the application to the display server use much less bandwith so you don't need compression so less latency (or less compression plus compressing the background independently of the text would give much better compression) .

AFAIK, kristian, the wayland developer, had a working implementation of remoting images with deltas. Also he is doing some work on a rolling hash [1] implentation, which should speed things up. But I am not an expert and don't know how usable that will be.

[1] http://cgit.freedesktop.org/~krh/rol...1423e2fe4ced90
EDIT: scroll down to the ideas

[dee.]

This is not 100% true you can configure Qt to use XRender for example.

That's one toolkit, and an option almost no-one uses, because it's unnecessary overhead and slowness.

HD video use compressed delta images: here you are streaming full uncompressed image,

Says who? Who says you can't stream compressed delta images to the remote wayland client? Besides, the way I understand it, Wayland already uses delta for surfaces, clients only need to send the changes to the surface they're drawing on.

it's even worse in bandwith, especially when everyone will have "retina-display" monitors!
Yes, you can compress the buffers but it adds latency which is *bad*, sending text from the application to the display server use much less bandwith so you don't need compression so less latency (or less compression plus compressing the background independently of the text would give much better compression) .

Meh, we can use GPUs and/or specialized chips to compress/uncompress video, it's not going to be a real problem, quit living in the past.

[JS987]

That's one toolkit, and an option almost no-one uses, because it's unnecessary overhead and slowness.

Native Qt4 backend is 2-6 times faster than raster one in qtperf4 - tested on 2 Intel GPUs.
GTK/Cairo is also using XRender.

[bwat47]

I'm talking about the http://en.wikipedia.org/wiki/Desktop_Window_Manager. And yet applications from before that weren't designed with DWM in mind still can work (some don't obviously), whereas in linux you have to port your application to a toolkit that supports wayland.

I'm not really familiar with how these windows internals works, but perhaps windows has some sort of seamless backwards compatability that allows this, like wayland has with xwayland?

[renox]

Says who? Who says you can't stream compressed delta images to the remote wayland client?

You can but it adds latency, not an issue with pre-recorded movie, not so good for a GUI.

Besides, the way I understand it, Wayland already uses delta for surfaces, clients only need to send the changes to the surface they're drawing on.

Link? Besides it doesn't help for scrolling text.

Meh, we can use GPUs and/or specialized chips to compress/uncompress video, it's not going to be a real problem, quit living in the past.

So you have (1) a program running on the CPU, sending instructions to render buffer on the GPU, then a special pass on the GPU to compress the frames (just doubled GPU memory usage BTW) then re-reading the GPU memory to be able to send it through the Ethernet card instead of having (2) a program sending directly the drawing command to the Ethernet card, that is progress to you?
(1) make sense when you want to do complicated stuff, but for drawing text (which is still a very important part of the desktop), this is a regression: it adds latency, increase bandwith usage for nothing.