> Is there a bug report for this in the Qt bug tracker that you can share? "A" bug report? There is like tens of them. A 5 minute search reveals many: Main bu

> Is there a bug report for this in the Qt bug tracker that you can share? "A" bug report? There is like tens of them. A 5 minute search reveals many: Main bug: * https://bugreports.qt.io/browse/QTBUG-56851 https://bugreports.qt.io/browse/QTBUG-56851 Similar bugs: * https://bugreports.qt.io/browse/QTBUG-67170 https://bugreports.qt.io/browse/QTBUG-67170 * https://bugreports.qt.io/browse/QTBUG-47069 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-19636 * https://bugreports.qt.io/browse/QTBUG-25761 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 https://bugreports.qt.io/browse/QTBUG-70387 In stackoverflow, plenty: * https://stackoverflow.com/questions/22017200/is-there-a-way-to-reduce-the-amount-of-x11-traffic-produced-by-qt-creator https://stackoverflow.com/questions/22017200/is-there-a-way-... * https://stackoverflow.com/questions/28782162/serious-performance-problems-with-qt5-and-x11 https://stackoverflow.com/questions/28782162/serious-perform... Bringing back the option to draw using X: * https://twitter.com/peha23/status/1037294277859131392 https://twitter.com/peha23/status/1037294277859131392 * https://sourceforge.net/p/qwt/mailman/message/36418978/ 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).