Originally posted by farnz
View Post
Announcement
Collapse
No announcement yet.
The Wayland Situation: Facts About X vs. Wayland
Collapse
X
-
Originally posted by renox View PostAnd these images of the individual character are cached and reused which means that it much more bandwith efficient than Wayland..
Comment
-
Originally posted by mrugiero View PostI 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.
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!!
Comment
-
Originally posted by renox View PostNo 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!!
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?
Comment
-
Originally posted by dee. View Post1) 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?
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) .
Comment
-
Originally posted by renox View PostThis 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) .
[1] http://cgit.freedesktop.org/~krh/rol...1423e2fe4ced90
EDIT: scroll down to the ideasLast edited by giselher; 11 June 2013, 12:14 PM.
Comment
-
Originally posted by renox View PostThis 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) .
Comment
-
-
Originally posted by garegin View PostI'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.
Comment
-
Originally posted by dee. View PostSays who? Who says you can't stream compressed delta images to the remote wayland client?
Originally posted by dee. View PostBesides, 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.
Originally posted by dee. View PostMeh, 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.
(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.
Comment
Comment