3 ms·

>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

>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 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 https://support.google.com/youtube/answer/1722171 To me, the compressed video solution is the clear winner.

AshamedCaptain 6y ago
> 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).
- cycloptic 6y ago
  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.
  - AshamedCaptain 6y ago
    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).

AshamedCaptain 6y ago

> 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).

cycloptic 6y ago
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.
- AshamedCaptain 6y ago
  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).