[tgot]

Network transparency meant that when I was doing Finite Element Analysis on the beefiest Sun workstation they sold, running a proprietary application, I could log in from home, run the application on the Sun, and see the results of the prior run.

I could edit the model, regenerate the mesh if needed, and kick off another big batch run, and then drop the X11 frontend GUI.

Over dial-up, from a Windows box to a Sun workstation, in the mid 90s. And it was could be secure, tunneled through SSH.

[cycloptic]

I'm assuming that was sending OpenGL 1.0 commands over the network, or doing some kind of equivalent. Using X11 drawing commands for that would have resulted in miserable frame rates over dial-up if you ever tried to rotate or zoom the mesh. In any case that's not really network transparency nor is it really X11, the program likely had to be built in a very specific way using display lists.

[ddingus]

CAD and Simulation Apps were written in those specific ways.

You are right.

Where that was done, performance was excellent.

[cycloptic]

It just seems wrong in that case to to say that X is network transparent. The real concern is that OpenGL 1.0 was capable of running over the network, and in order to use it effectively application developers had to take network operation into consideration, and the server had to support the non-standard extension required to use it correctly. In some circumstances using display lists locally could actually reduce performance, so the application may not have wanted to take that path in all cases: https://www.opengl.org/archives/resources/faq/technical/disp...

Generally if your application has any code that does this:

    if (client is remote)
        ...
    else if (client is local)
        ...

Then I wouldn't say the protocol you're using is network transparent.

[ddingus]

Open GL could run over the network because X could.

Sgi used X fully. They wrote the book on all that, including GLX, and it was flat out awesome.

The Apps I used all ran display and pick lists. They worked very well over the wire and that use case for used a lot.

The quibbles are really getting past the basic idea of running an app remotely on ones local display.

That happened and worked well and had some advantages. I personally built some pretty big systems for modeling and simulation that were cake to admin and very effective on many other fronts.

Notice I did not say network transparent in my comments above.

Multi-use graphical computing is much more accurate when it comes to how X worked and what it delivered people.

[ddingus]

BTW, display performance on those was great local. A small hit locally is not that big of a deal. Never has been.

Users will employ detail limits, model scope limits, whatever to get the UX they need.

Developers can dual path it, or provide options. And they will provide options because not all users have latest and greatest. They never do.

In the end, it is mostly a wash for most things.

The big gains were had in other areas.

In the CAD space, sequential CPU is far more of a bottleneck. Mid to lower grade GFX subsystems perform more than good enough for a ton of cases today. Can't get a fast enough sequential compute CPU. And while there is serious work to improve multi threaded geometry, fact is most important data is running on crazy complex software that needs the highest sequential compute it can get.

Big data actually sees a gain with the X way of doing things.

Huge model data running over shared resources is a hard problem. And it continues to be one. Mix in multi user and it takes serious tools to manage it all and perform.

In the 90's, many of us were doing those things, multi user, revision control, concurrent access, you name it on big models and fast, local file systems. There was software with all that well integrated. We did not have cloud yet. Not really.

The app server model rocked!

X made all that pretty easy. One setup, and just connect users running whatever they want to, so long as a respectable X server is available, they are good to go.

One OS, the whole box dedicated to one app, fast storage, big caches, multiple CPUS all tuned to get that job done well and perform.

Once that work is done, doing things the X way means it stays done, and users just run the app on the server. Bonus is they can't get at that data directly. Lots of silly problems just go away.

And, should that system need to be preserved over a long period of time? Just do that, or package it all up and emulate it.

In all cases, a user just connects to run on whatever they feel like running on.

Those of us still talking about how X does things see many advantages. Like anything, it is not the be all end all. It is a very nice capability and a "unixey" way of doing things being lost.

[destructionator]

It is quite possible it just sent draw line requests as a list of vertexes after doing all the math on the client, which core x supports just fine.

[cycloptic]

That takes huge amounts of bandwidth. There's a reason display lists were necessary to get it to work on dial-up connection.

[umanwizard]

It means that _today_, I can run an IDE on my 32-core home desktop and interact with it seamlessly on my 13-inch laptop at the office. I'm not sure whether this is possible with Wayland.

[mcguire]

https://wayland.freedesktop.org/faq.html#heading_toc_j_8:

Is Wayland network transparent / does it support remote rendering?

No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.

This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server, but other options include an RDP server, a VNC server or somebody could even invent their own new remote rendering model. Which is a feature when you think about it; layering X.org on top of Wayland has very little overhead, but the other types of remote rendering servers no longer requires X.org, and experimenting with new protocols is easier.

It is also possible to put a remoting protocol into a wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor. This will let us forward native Wayland applications. The standalone compositor could let you log into a server and run an application back on your desktop. Building the forwarding into the desktop compositor could let you export or share a window on the fly with a remote wayland compositor, for example, a friend's desktop.

[cycloptic]

See waypipe for an example of how this can be done "natively": https://gitlab.freedesktop.org/mstoeckl/waypipe/