Re:Xplain – Explaining X11 for the rest of us (2017)
by cycloptic on Tuesday August 18, 2020 @05:58PM
(#24204843)
Thank you for those bugs. They seem to further the point that X11 is not network transparent, seeing as how the solution was for Qt to support two separate xcb backends, one for local rendering and one for remote rendering. And actually a third for local hardware rendering using GL.
I have no comment on NX, I've never used it.
Re:Xplain – Explaining X11 for the rest of us (2017)
by AshamedCaptain on Tuesday August 18, 2020 @06:12PM
(#24204962)
Qt _needs_ a non-X11 backend, seeing that it runs on platforms where X11 is not prevalent. Network transparency is another story and not related whatsoever to this since even if you push bitmaps X11 is still technically network 'transparent' (the quotes are due to the increased bandwidth usage).
"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).