Yes, Wayland doesn't dictate anything, and that's the problem! It is the moral e...

shmerl · on Dec 31, 2015

> What does Wayland provides in term of modern usages with modern tech?

More direct and simpler (and therefore efficient) way to deal with drawing. X is bloated with tons of overhead and obsolete legacy stuff.

Here is a good talk about it: (The Real Story Behind Wayland and X) https://www.youtube.com/watch?v=RIctzAQOe44

xorblurb · on Dec 31, 2015

Very interesting.

I'm glad they were sufficiently pushed to eventually start thinking about remoting.

I get that X protocol was not that good -- but I'm still not convinced that their model is, not even talking about future proof, suitable for present needs; you have to at least provision for multi-dpi, touch and changing form-factors; you also have to provision for multi-gpu more seriously (his answer: client pb and very difficult) and multimedia (sound synchro, ideally including in remoting cases).

I'm also not 100% convinced that the argument that gedit round-trips too much is a good one. You have to rewrite toolkit to use Wayland anyway, so why not comparing that approach to a mere cleanup of the way they use X?

And to finish, you will still need quasi perfect retro-compatibility with X for lots of users.

So if eventually all of that is handled properly, why not, and given how he said they orient the protocol descriptively more than imperatively this is possible that this can be added in a second time without falling again in X situation full of workarounds, but even in this best case scenario it will still be very late to the party, especially if they feel so much in the mood of stuffs like touchpad driver rewrite (why is that not in a common lower layer anyway?...). And even then, this will only go as far as the client who render every pixel will be able to do anyway... I get that this is more or less what is largely already done anyway by some software, but guess what else is also done today? Using X... so not a really good reason when you are already breaking everything anyway.

And also guess what a really efficient remote protocol focused on bitmaps would intrinsically be kind of equivalent to for a lot of use cases? Describing transformation operations on previous images already known by the server. There are tons of operations which today exists and that are reimplemented in web browsers as hacks of e.g. javascript and tilled jpegs; either future "display" stacks are powerful enough to model them efficiently, or we abandon all hopes and the native graphic stack should just be a glorified frame buffer and the real UI should be implemented in a browser -- after all, that's also what is partly already done!