Is there a bug report for this in the Qt bug tracker that you can share?
>It's mostly a several megapixel black bitmap with a couple million white lines rendered on it. Relatively easy for a "drawing primitives over the wire" solution, insane for anything that tries to encode it as realtime video.
I think your math is off. In the X11 protocol, each line segment is transmitted as 8 bytes. Transmitting two million white lines uncompressed is going to take up 16 megabytes. Do that 60 times a second and now you have a bitrate of 960MB/s. Compare this to youtube's recommendations which suggest a maximum bitrate of around 10MB/s for 4K HDR 60FPS video: https://support.google.com/youtube/answer/1722171
To me, the compressed video solution is the clear winner.
"A" bug report? There is like tens of them. A 5 minute search reveals many:
Main bug:
* https://bugreports.qt.io/browse/QTBUG-56851
Similar bugs:
* https://bugreports.qt.io/browse/QTBUG-67170
* https://bugreports.qt.io/browse/QTBUG-47069
Bugs already filed back in qt4 release when the default was changed (but the x11 code could still be enabled):
* https://bugreports.qt.io/browse/QTBUG-19636
* https://bugreports.qt.io/browse/QTBUG-25761
People complaining whenever the new X11 render path gets broken on qt5:
* https://bugreports.qt.io/browse/QTBUG-70387
In stackoverflow, plenty:
* https://stackoverflow.com/questions/22017200/is-there-a-way-...
* https://stackoverflow.com/questions/28782162/serious-perform...
Bringing back the option to draw using X:
* https://twitter.com/peha23/status/1037294277859131392
* https://sourceforge.net/p/qwt/mailman/message/36418978/
> compressed video solution is the clear winner.
This is enlightening, but it is still comparing apples to oranges, or in this case, compressed to uncompressed. The cost of encoding video cannot be disregarded. And for starters, even if you use hardware encoding, they hardly do any type of variable bitrate; you are likely to get almost the same bitrate even if the screen only changes slightly (good luck sending partial damages to a hardware encoder). On the other hand, NX compresses all traffic by default, and so does SSH (but not by default).
Not to mention that compressed video at this rate would show artifacts. Even at bluray rates artifacts can be seen in motion film; let's not even get started what you would see for this type of content.
Do note that I am highly biased here since we (my company) constantly evaluates potential solutions almost every other week to do remoting (e.g. RDP/extremeFX, PCOIP, Blast, you name it) , and _every_ _single_ _time_ customers end up falling back to an ANCIENT NX version (cause the newer ones also use video "sometimes") which is so full of bugs I consider it the a modern equivalent of torture. (By the way, xpra, freenx, and every other open source NX fork are also the same -- ancient NX 3.xx versions). I really would like to kill that with fire but there's absolutely nothing comparable in terms of (in)sensitivity to high-latency links, low bandwidth usage, image quality, and even economy (no GPU video encode farm thanks).
I have no comment on NX, I've never used it.
You answer it later on. They want something like NX. We can fill in the details as one pleases.
> We know how to design much more resilient systems than that.
I think you are overstimating the progress of computer/network engineering. Anyway, CORBA's "transparency" might be a thing of the past, but what's the point here? Unless you plan to make a graphics API explicitly asynchronous, what alternatives you have? Sending PostScript over the wire? :/
The users want graphic primitives sent through the wire. There is not much alternative other than CORBA style RPC.
> Not to mention that ever since the introduction of the MIT-SHM protocol, which is used by most everything to transfer image data, it hasn't even been true in practice for the last 20 years
That is not true. See how many commercial Qt engagements were stuck with Qt 4 because Qt 5 initially forced to use Qt's local rendering and only pushing the final pixmap to the server. Multi-million CAD machines slowing down to a halt because the clients were suddenly sending megabits through the pipes * . Eventually they had to backpedal and Qt5 now offers coreX/Xrender rendering too. _Most_ toolkits _to this day_ still render with X by default, and people do notice when this changes (see Mate). Sure there are exceptions and likely amongside the most used software (e.g. browsers), but I'd hardly claim "anything but MIT-SHM is all that matters for the past 20 years".
> is a network-designed fork of the protocol,
Yet compatible (to a high degree, at least). Up to the point the "transparency" illusion is maintained.
> Problems like remote desktop and streaming can be solved by other solutions
The biggest problem is that once you drop the codeflow on most opensource programs that renders using X, it's code that's rotten forever, and this entire method of "network transparency" will never be workable again in the free desktop world. Everyone and their mother will draw in a different way.
We'll have to resort to full video streaming or the like that have their own share of disadvatanges. There is absolutely no technical reason behind this, it's just a "code is done by volunteers" problem.
* And please don't say VNC/video here, since this is CAD. It's mostly a several megapixel black bitmap with a couple million white lines rendered on it. Relatively easy for a "drawing primitives over the wire" solution, insane for anything that tries to encode it as realtime video.