This is true but VNC doesn't exactly win any awards in the performance department in general. Sending bitmap diffs is pretty much the least efficient most naive way to do remote desktop. What VNC has going for it is that it's dead simple to implement because of that fact.
X forwarding goes the complete opposite direction to pipes the whole X protocol over the network. Convenient -- yes, also dead simple to implement -- yes, actually works -- well no. You see the X ecosystem also assumes all rendering is local, that fact is just hidden in edge cases. For example Nvidia graphics work on X with an extension that both has a client and server component -- as soon as you forward X traffic that's looking for the server-side extension... crash.
RDP by contrast does the right thing(tm) but also the hard thing by defining an intermediate object model which is semantic enough to kill the need to send pixels over the wire most of the time but flexible enough to allow for it when necessary.
RDP something like RDP is the correct answer - I thought it worked by effectively streaming GDI calls over the network - well that and whatever they used to replace GDI for 3D enhancements.
I'd agree with you for modern applications that are not well written, I've been running X applications over the network however for 20 years or so, and outside of things like.. well 3D applications, network X works pretty well - my only real complaint was not including sound too.
NCD (Network Computing Devices), who made X Terminals, came up with a sound server called "NetAudio", based on the X11 server, protocol and client library, with the graphics ripped out and sound stuck in.
I used it in the early 90's to support the Unix/X11/TCL/Tk multi player version of SimCity, with a scriptable TCL/Tk audio server that could drive either /dev/audio on Sun/SGI/etc or NetAudio on NCD X Terminals. Other TCL/Tk clients like SimCity (but possibly others) communicated with it via the TCL/Tk "send" command, which bounced messages off the X server.
NetAudio had its problems, but basically worked. Except that it insanely mixed audio by AVERAGING (add waveforms then divide by the number of sounds) instead of adding and clipping, and I couldn't convince the NCD engineer that was the wrong way to mix sound, and to just add and clip instead, like sounds mix in the real world: When you talk over music, the music volume and the volume of your voice doesn't magically lower by half. Hopefully they've fixed that problem by now.
I’m fine with that tradeoff. For people who need network rendering, they can pay a performance penalty when they use it. For the 99% of people who 99% of the time don’t use this feature, we aren’t paying the performance (and architectural complexity) cost of this.
Electron is panned by many these days for requiring an expensive network system for a local process. Why doesn’t X11 get the same scorn? Have we forgotten the days when a Mac could run a GUI in 128K while a Unix system struggled to run x11 (with no clients) in 4MB? X is heavy.
In the late 80's, context switching was so slow and local area networking was fast enough that it was sometimes actually snappier to run your xterm or emacs on another system over the local network, than both on the same workstation.
That's because running over the network didn't require ping-pong context switching back and forth between the X11 server and the client at every keystroke, so both client and server could run smoothly without getting switched out.
The X protocol is so chatty and ping-pongy that it could require several context switches per keystroke to handle the event and update the screen, when running both server and client locally!
> Electron is panned by many these days for requiring an expensive network system for a local process. Why doesn’t X11 get the same scorn? Have we forgotten the days when a Mac could run a GUI in 128K while a Unix system struggled to run x11 (with no clients) in 4MB? X is heavy.
If you actually properly understood both the argument you're making and the reason why most people dislike Electron and friends, then you'd not be making that argument. I'll give you the benefit of the doubt and assume you're joking.
Actually, Electron (and most other web browsers) on the Mac OS/X and iOS use IOSurface to share zero-copy textures in GPU memory between the render and browser processes. Android and Windows (I presume, but don't know name of the API, probably part of DirectX) have similar techniques.
It's like shared memory, but for texture memory in the GPU between separate heavy weight processes. Since simply sharing main memory between processes wouldn't be nearly as efficient, requiring frequent uploading and downloading textures to and from the GPU.
Because when attacking your parent poster, you neglected to explain your argument, and the reasons why you believe most people dislike Electron, and why X11 doesn't get the same scorn, which caused you to be downvoted.
Care to elaborate, please?
Do you know if X11, like Electron, supports shared memory textures in the GPU like IOSurface and GL_TEXTURE_EXTERNAL_OES are for?
> Because when attacking your parent poster, you neglected to explain your argument
I can't force someone to understand something that they do not want to. More than enough people have written, much more eloquently than I, about why electron is bad. None of the critiques I've seen are 'because it relies on an expensive network system'.
EDIT: Hell, even if we assume that the critiques are about "expensive networked system"s, Electron is still incomparable to Xorg so the root-parent's post is making a false comparison.
X performs better than VNC for stuff like xscreensaver, but not usually for video or applications that do dumb stuff like cute animations of internal windows opening. VNC just drops out the frames and catches up. X tends to render to perfection each graphic context call.
