We Have Mir & Wayland, But There Still Could Be X12

[Remote User]

Note that most of it is remote displaying and not remote rendering.
Remote rendering is sending commands across the network, and rendering on the client.
Remote displaying is rendering on the server, and send rendered parts across the network.

The first is what the core X11 protocol is capable of. Because it acts as a toolkit.
But extensions of the protocol used by 90% of X apps are not remote rendering capable (because most of other toolkits, including gtk and qt, render render themselves and give bitmaps to the X server), and so you only get remote displaying.
Which is achievable by any display server, really.
It is, as other people said here, akin to unoptimized VNC. It certainly works, but it surely isn't a compelling reason to keep X11 architecture.

I'm among the 10%, and using my own toolkit. My apps DO render remotely on the X server. As I mentioned to another person here, your assumptions are somewhat pedantic, they are wrong, and the conclusions drawn from them do not contribute to this discussion.

[erendorn]

No, I do not send 'dumb images' across the network. I use Xlib to render the GUIs. You are making the same assumptions that nearly everyone else makes, that anyone doing remote display is NOT doing it with the X protocol, and they, like you, are wrong in your assumptions and in any conclusions you draw from them.

But maybe my assumptions work better with respect to the post and user I was actually replying to?

Otherwise, I'm still of the opinion (shared by other posters, apparently), that what you need is a remote rendering toolkit, not a given display server that happens to have such a toolkit embedded in it.

That is certainly a better design for any future application, and legacy applications, well, are bound to use legacy systems.

[movieman]

Otherwise, I'm still of the opinion (shared by other posters, apparently), that what you need is a remote rendering toolkit, not a given display server that happens to have such a toolkit embedded in it.

If you're going to have a standard remote rendering toolkit, why not, you know, make it part of the standard display server?

If you're not going to make it a standard, how is every app going to display on any device you happen to be using? X11 allows me to run Unix apps and display on any variant of Unix, Windows, and pretty much every other OS that has more than minimal display capability, because they all have to support the same protocol.

And, yes, most apps I run remotely quite clearly don't send bitmaps over the X protocol, because performance on the ones that do sucks ass, and performance on the ones that don't send them sucks ass if I have to switch to an alternate method of network rendering which does convert them to bitmaps.

[mrugiero]

Otherwise, I'm still of the opinion (shared by other posters, apparently), that what you need is a remote rendering toolkit, not a given display server that happens to have such a toolkit embedded in it.

I second this. However, I think if a X12 materializes, this toolkit should be part of the core protocol. I believe network transparency is one of the aims of X protocols.
However, I do not see a reason to make a X12 protocol, really. That would probably just fragment things even more.

If you're going to have a standard remote rendering toolkit, why not, you know, make it part of the standard display server?

Because that's how you end up with a bloated and impossible to cleanly upgrade display server. You shouldn't put things with very specific uses into the general purpose solutions. If it would be X12 and it would be specifically tailored for network transparency and workstations and such, it's OK. But a lot of people thinks that feature belongs into core Wayland, when Wayland aims to make for something lean.

If you're not going to make it a standard, how is every app going to display on any device you happen to be using? X11 allows me to run Unix apps and display on any variant of Unix, Windows, and pretty much every other OS that has more than minimal display capability, because they all have to support the same protocol.

The same way X11 does it, making your program depend on it. The toolkit may be standard, but it doesn't need to be embedded into the core protocol nor the server.

And, yes, most apps I run remotely quite clearly don't send bitmaps over the X protocol, because performance on the ones that do sucks ass, and performance on the ones that don't send them sucks ass if I have to switch to an alternate method of network rendering which does convert them to bitmaps.

Congrats for that, but it still has a number of users marginal enough to not be embedded into the core of things.

[Remote User]

But maybe my assumptions work better with respect to the post and user I was actually replying to?

Otherwise, I'm still of the opinion (shared by other posters, apparently), that what you need is a remote rendering toolkit, not a given display server that happens to have such a toolkit embedded in it.

That is certainly a better design for any future application, and legacy applications, well, are bound to use legacy systems.

Yeah, well, you and a couple of others do not have or use remotely rendered applications but have some opinions about people who do, then there are those of us who DO have and use remote rendering toolkits, (mine since 1995) and remote rendering gets better with each release of the X display server the xlib client libraries, ssh and Linux.

As far as 'legacy systems', well, I have no idea what you mean in the context of this discussion unless you want to provide a few relevant examples. Would you make your point, again?

[erendorn]

Yeah, well, you and a couple of others do not have or use remotely rendered applications but have some opinions about people who do, then there are those of us who DO have and use remote rendering toolkits, (mine since 1995) and remote rendering gets better with each release of the X display server the xlib client libraries, ssh and Linux.

As far as 'legacy systems', well, I have no idea what you mean in the context of this discussion unless you want to provide a few relevant examples. Would you make your point, again?

Sure, still was an answer to someone who said was remoting firefox. but whatever.

In a discussion about the successors of X11, the legacy system is X11.

So I'll make my point again:
a) Remote rendering is a toolkit thing (even in X11, it really is akin to a toolkit)
b) Toolkits can be made separate from display server (there are already multi platforms toolkits)
the hypothesis is:
c) There shouldn't be too many things in the display server (that I cannot demonstrate, so feel free to disagree. but it seems to be the common opinion of most of the X server's devs)
And then, the point:
If you make a new display server, instead of making one with a remote rendering toolkit in it, you can (and thus, from c, should) make a display server and a separate remote rendering toolkit (or readily use one if such thing exists).

And, from the user point of view, applications that cannot be ported will have to use X11 anyway, because porting to the new display server or the new toolkit is the same thing. Application that can will work at least as well as before, except that they will not be limited in either the server or the client side system (if someone ports the toolkit to new display servers). So making them separate is again transparent or positive.

[Akka]

Yeah, well, you and a couple of others do not have or use remotely rendered applications but have some opinions about people who do, then there are those of us who DO have and use remote rendering toolkits, (mine since 1995) and remote rendering gets better with each release of the X display server the xlib client libraries, ssh and Linux.

As far as 'legacy systems', well, I have no idea what you mean in the context of this discussion unless you want to provide a few relevant examples. Would you make your point, again?

But what you use is a remote rendering toolkit. I can not see what it has to do with wayland as wayland don't have a intern toolkit in the same way. You could as well have a external toolkit with this capabilities. Have it in the x server is not a benefit.
Also to get xlib based remote rendering, use XWayland.

[YoungManKlaus]

without reading the rest ... why would X12 happen now? After all there has not been any real progress for the last ~20 years ...

[MartinN]

What would the advantage be of renaming Wayland to X-something?

nothing. It would sap Wayland of its paradigm shifting power by associating it with a dead legacy, X11. Naming is important, and anything that starts with X, as others have pointed out, should perish.

[ryao]

Note that most of it is remote displaying and not remote rendering.
Remote rendering is sending commands across the network, and rendering on the client.
Remote displaying is rendering on the server, and send rendered parts across the network.

The first is what the core X11 protocol is capable of. Because it acts as a toolkit.
But extensions of the protocol used by 90% of X apps are not remote rendering capable (because most of other toolkits, including gtk and qt, render render themselves and give bitmaps to the X server), and so you only get remote displaying.
Which is achievable by any display server, really.
It is, as other people said here, akin to unoptimized VNC. It certainly works, but it surely isn't a compelling reason to keep X11 architecture.

Apple went off on its own direction with the Quartz Compositor. The result is argued to be the equivalent of what we have today with X11:

http://www.informit.com/articles/article.aspx?p=1552774&seqNum=5

The fuss over Wayland and Mir seems to be a repeat of what Apple did and I do not see the point. The argument "we are doing it because we can" is fine, but I would prefer to see it done without the hype. The only way that a different display server could improve things would be if they was already room for improvement and I do not see it with Xorg.