Kinda yes kinda no? Mostly from X drawing commands being a shit way to represent modern UI's and toolkits. So everyone draws stuff on their own, since it's far more flexible and faster.
Same is true on windows. RDP is streaming video far more often than it steams drawing commands.
You could maybe build something that streams GPU commands, though. Use something like VirtIO-GPU + GFXSTREAM ( https://www.phoronix.com/news/VirtIO-Context-Type ) to stream to an entirely different computer instead of just to the VM host?
This is really fundamentally wrong. X drawing commands are still just fine for representing modern within-app UIs and toolkits.
The two things that have changed are the underlying GPU technology, which has shifted towards abstractions and APIs mostly targetting gaming and video, and desktop level UI stuff, which is expected to include compositing these days.
However, it's not as if the other remote desktop systems have really changed much to reflect these developments either.
This is really fundamentally wrong. Nobody has been updating X commands for modern effects (eg, blurs, advanced blend modes, etc..). Heck you can't even do round-rect clipping. You have to generate a clip mask pixmap instead. At which point I might as well just generate the final pixmap and forget about X anything. Especially since xlib doesn't even do anti aliasing. Like come the fuck on, it's friggin useless. Can't even handle text adequately!
There's a reason Wayland dumped it all entirely. If it had been maintained and updated sure maybe. But it wasn't. It's a drawing library straight out of the 90s, absolute abandonware
Faster for which usage? Locally yes, but not remotely where it's worse..
In the beginning Unix desktops were optimised for LAN, and in the process of being optimised for standalone PCs to the dismay off those who access their Linux desktop remotely..
How do you know it's actually worse for remote? I can render my entire UI on the GPU & route that straight into a video encoder incredibly quickly. Faster than XLib can draw in the first place.
Now there's the bandwidth question there yeah. The video stream takes X Mbps, and the Xlib stream takes Y Mbps. Unless you've measured it recently, you don't actually know if X or Y is smaller. You can make a guess that xlibs is smaller, sure. After all it's vector, right? Except it isn't, not really. Text is all pixmaps. Images are all pixmaps. Path clipping is all pixmaps. Are you compressing all those pixmaps before sending? If so, to what? And is that faster than your GPUs h264 encoder? Almost certainly not. Is it smaller? Also probably not really.
And I don't know about you, but I got way more bandwidth than I have latency for my Internet connection. So whether or not X or Y is smaller doesn't actually matter to me. What matters is which gives me less end to end latency, which all but certainly is the video encoder & decoder path, which are incredibly well optimized and hardware accelerated.
Because I've tried `ssh -X` and in my experience it sucks for any "modern" program (that I've used; I suppose there's bias in my sample).
Blit
Blit
Blit
Blit
Blit
Blit
Blit
Here's e.g. dolphin rendered with it here over ssh: https://imgur.com/bLnop55
> All of them except blitting pixmaps are basically not useful for a modern desktop.
that's ridiculous. Most software is basically a succession of drawLines / drawRect calls with the occasional pixmap.
All of the text, for example, is rendered by QT and sent as pixmaps. The drawTextItem path doesn't ever attempt to use XDrawText
Anyways, what matters to me is that I can resize the window without any lag and compression - it immediately becomes much more laggy and redraw-artefact-y if I disable X11 painting when I access my remote machines so it's pretty obvious when things are using it
... but those buffers are going to be paint with the same calls to drawRect. If I look at my software's draw calls, the huge majority are calls to such drawLine / drawRect / drawRects with the occasional small text or pixmap
X11 is at its heart an asyncrhonous distributed systems protocol (quite similar to Erlang Dist) that happens to output to the screen as a side effect, but a lot of libraries and toolkits (including xlib) provide synchronous abstractions on top. When applications use synchronous abstractions frequently, you end up waiting for many roundtrips and the UI gets painfully slow. Some app developers regularly test with remote X over high latency and/or low bandwidth links, and some don't, and it's pretty easy to tell which is which. Some apps are painful even on a LAN, lots of roundtrips add up.
If there was appetite to do the work, one could imagine an extension to push client-side rendered window images across in a compressed format, but xorg developers have mostly moved on. There's nx and other external compressors, but there's a missed opportunity, IMHO. Maybe waypipe will fill this void eventually?
Take Xterm, for example. I did benchmarks over remote systems long ago. When it came to performance over the network it was absolutely trounced by Gnome-Terminal. And Gnome-terminal was a lot slower then then it is now. The reason was because Gnome optimized text output on scrolling text that minimized the latency impact. And it still sucked.
There was a reason that it never saw widespread use in the enterprise outside of very nitch sysadmin users on pretty much local area networks.
Were as Windows has been used to support thousands of users in a single environment with almost entirely remote applications for a very very long time now. For most users and most applications there is no difference in functionality between remote and local applications.
Were as X11 will never be able to accomplish that unless the computer is sitting in the room next to you. Nomachine and similar tech can speed it up, but that isn't really X11 is it?
It's turning things upside down. Windows has been used in remote because it became dominant, not vice versa. It won in enterprise segment before e.g. even remote support, not to mention remote apps became widespread. And Win's success wasn't that much related to its technical excellence as most of admins from 90s would say
If you mean connect remotely to a desktop that someone else is using on another machine, yes that is indeed a different use case.
Eg, my kvm (virtualization) host runs RHEL and no desktop environment, but I can easily run virt-manager using X forwarding over SSH when I'm creating a new VM and a GUI is easily than writing a domain XML
In face I've forwarded virt-manager to Linux, macOS (XQuartz) and Windows (WSL w/ X server)
However, this isn't why people want to use the "remote desktop" protocol. The app that I'm accessing over RDP isn't something I'm running after I connect to RDP: virtually all of the time it is an app that has been running for weeks and will remain running for weeks to come.
I am using my computer right now, after having woken up from a nap. This computer is doing all the things I left it doing when I went to take that nap. It has a bunch of state for all of these running applications, and if every time I walked away from my computer all of that state disappeared, I'd be annoyed, as I want to be able to sit down at my computer and do five minutes of work and then go off and do something else and come back and do five minutes more of work.
This is the primary use case for the remote desktop protocol: I leave a bunch of software running on my desktop and then I go somewhere else and I can remotely log in to my desktop and see all of my running programs. If I have spotty wifi and I only manage to get connected for 30 seconds before I get disconnected, I can just reconnect and everything is exactly where it was as I wasn't logging to run anything: I'm accessing things that are already running.
So, no: "at the end of the day" these are fundamentally different use cases, and the former use case simply isn't something I feel like I ever want to do. Hell: it isn't even what I generally want with a terminal! (I had always set myself up so I had running static screen sessions going that I'd remotely connect into, and then I use either autossh or a little bash function running ssh in a loop to reconnect to that remote screen session so when I open my laptop it steals my terminal from wherever I was using it last to my local display.)
The premise of remote desktop connections is something which kind of changes how you use your computer: once you try it and get used to it, you start to treat the terminal you are at as a commodity, as every computer not only has access to your files but every computer has the same state and let's you immediately jump right in to where you left off with your work. In contrast, I'd claim the use cases where you want to, while you are out, run an app on a computer you aren't at is a niche use case.
A seamless experience of passing off a single session across multiple entry points seems like the holy grail of personal computing. I'm willing to accept slightly different experiences between my MacBook, Windows desktop, and iPhone - but I want to feel like I'm picking up where I left off.
In some ways this is starting to happen within certain suites of products, for example, Chrome session handoffs. Nonetheless, it's not a remotely consistent computing experience.
I'd bet it's an incentivization problem at this point, and therefore I wouldn't hold my breath.
"I can pretty much always run the graphical program locally instead"
Then why do you need a remote desktop? This is a really strange comment, because you shouldn't ever care whether the window manager is local or remote (as with XDMCP) - the only thing that should matter is whether the apps are local or remote. Whatever it is you're doing with apps on a remote desktop can be done better by simply displaying the app remotely on your own desktop.
What exactly is the use case for needing to run a second window manager remotely? It's such a strange thing to say that you need.
Now, I go somewhere else. While I'm out, I realize "oh, I need to change the queue on my encoding software" or I want to talk about some web page I have open. This is what Remote Desktop on Windows is doing for me: I don't connect to my computer remotely and then have some abstract notion of "I guess I can run software at home but see it here"... I actually am able to make that computer I'm at--wherever it is, and whatever it is (often it is my phone! the RDP clients for iOS and Android are excellent)--equivalent to the computer I have at home.
As far as I have ever understood--and I'm NOT an expert at X, though I've been using it for 25 years in various capacities ;P--X fundamentally doesn't do that: X clients connect to X servers, and if the X server dies then the X client also dies. The Window Manager--the behavior and interaction of which in this system I, in fact, care about deeply--also connects to the server. I have never come across a use case where I'd want to run a graphical app on one computer and merely have it display on a local computer: in that case, I can simply run that app locally.
However, what has given me superpowers is the ability to run the entire stack remotely and then "connect to it" from a local computer. I don't want to, while I'm out, run a new web browser process at home and have it appear on whatever device I'm at... I want to have the web browser I've already been running--along with all of its windows, all of their tabs, and their running state that have been actively continuing to execute and do stuff while I'm out--appear on the computer I'm at, making it feel everyone's computer becomes "my computer".
Generally speaking, the workflows I try to use center around sharing data between hosts. The tabs in your web browser should be in your history and that's synced between your systems, etc etc.
Regarding rehoming X apps, X can do that with tools like xmove. I haven't ever really bothered to use them because I have no use for that use case, but I do know they exist.
I've always used screen for re-attaching terminals. Batch jobs and background computations are generally logging to files which I can check or interact with from anywhere. That sort of stuff isn't ever connected to a graphical interface in my experience.
The benefit of remote display was, I think, more clear back when there was a greater diversity between systems. I would quite often run graphical tools unique to one unix on the my own system which was fundamentally incompatible (system-wise, cpu arch-wise, etc). Nowadays it's probably all x86 linux, so who cares, right?
https://github.com/Xpra-org/xpra/blob/master/docs/Usage/READ...
That contains some examples of how it can be used. I don't use it much, and I don't know if there are simply GUIs to make it easy to use.
With the advent of GPU, resolution, complexity of a scene all increased several times, making the problem essentially a completely different one than back in the XMotif days.
Think about video streaming, 3d acceleration, sound input and output.
Then whereas you previously had only a handful of vendors to coerce into agreement, now you have a multitude of individuals that are going to complain for every change.
Sadly things moved so quickly that when the X based terminals were new, people where quite excited to use them. However over the 5 years we used them they got noticeably less usable each year. We ended up replacing them with some diskless linux boxes that could run a 24 bit color window manager and browser locally (fast scrolling and window moving) and ran heavy graphical apps remotely over X11, things like Mathematica, Maple, and Matlab. The lab were suddenly much more in demand, and people hugely preferred them over the Mac and Window based labs students had access to. It was a nice mix of offloading servers (by running X11, window manager, and browsers locally) and offloading clients (by running memory intensive software on the server). People seemed to love the low latency keyboard, scrolling, and browsing. Waiting even a few seconds for Mathematica to churn through a notebook of forumulas and rendering was much easier with a responsive desktop. The diskless linux boxes were easy to admin, reliable, and quiet.
Basically browsing is hugely more data intensive than the era of X based terminals, even just scrolling animated windows is tough. Things like a full screen video at 4k was not even under consideration. At the same time people's expectations on performance, latency, and visual richness have increased to the point where X based terminals no longer make sense. Even fast 64 core servers with fast 8 core clients networked over switched GigE gives remote X11 a VERY poor experience these days. Try remote firefox over X11 sometime, it's painful.
I remember using X to run applications from half way across North America about 20 years ago. To be specific, I remember using it to do image editing in Gimp. Performance was great. Heck, I even used it over dial-up connections to my university. For some X applications performance was fine, though I was clearly using it for less demanding software.
Of course, expectations have changed. Microsoft has acknowledged this by continuing to improve upon Remote Desktop. I love and use the feature, even though I cannot stand Windows. While I use a couple of X applications over the network, for the most part I don't even bother. It's finicky to get working. Even when the fiddly bits are set up properly, there is no guarantee the software will work.
ssh -Y remote-host
...
% x-application-name
The ability to run graphical applications across a network may have distorted my impressions, but I am pretty sure I am remembering correctly. The modem experiences were largely things like previewing papers and preparing graphs, neither of which are terribly dependent upon interactivity. It is also worth keeping in mind that many early widget libraries were much simpler than what came later.