LXQt Now Has Full Qt5 Support

[erendorn]

You're wrong. The network transparency property does not state anything about bandwidth requirements. I see what you mean, but it's just not true. Given a fast enough connection even GTK3/Qt5 apps are usable over a network and look exactly the same. They don't send screenshots like you said. For example if I use MacOSX X client, I can freely move the windows and it does not repeat sending the window contents. That's when you remotely use apps & windows, not desktop. Even if RDP/VNC require less bandwidth IMHO they're just screen cloning apps and not network transparent in any way.

The connection bw is not a problem anymore. You can update 1920x1080 truecolor screen 20 times per second in a gigabit lan. GTK2/Qt4 still support some X features which means theey don't update whole screen so you actually get decent FPS unless you run a browser/video on fullscreen. I've tried it.

You're only a 10Gbps switch away from using a browser at 60fps then. Sound efficient.

It puzzles me that the only difference you see between screen copy and network transparency is the ability to send individual windows. Fear not, given how a compositor works, it is not very hard to send individual windows data.

[Vim_User]

It puzzles me that the only difference you see between screen copy and network transparency is the ability to send individual windows. Fear not, given how a compositor works, it is not very hard to send individual windows data.

The difference is that you don't even need a X server on the remote machine to send the data of an application Window over the network to a local machine, but when you want to do that how you describe you will need a full blown graphics stack.

[erendorn]

The difference is that you don't even need a X server on the remote machine to send the data of an application Window over the network to a local machine, but when you want to do that how you describe you will need a full blown graphics stack.

Wouldn't a web over http(s) application work better in this case? In particular if, say, you wanted to access your remote machine from a non X client machine?
Or any dedicated toolkit/protocol for the kind of applications used in that way (server GUI I guess), that would still be decoupled from the display server?

Aside from "But, but, legacy apps" reasons, of course.

[curaga]

Network transparency means render on client side.(not possible in modern X with any toolkit because only motif was supported and the code got broken years ago)
Network enabled means render locally and send raw resulting front-buffer pixmap to the client(what it works today)

Sending pixmaps does not mean it's not rendered client-side. Are you familar with the common CSS technique of a gradient image? 1x1024 pixels image, drawn N times to create a gradient background. In X terms, that is both sending a pixmap and rending it client-side N times.

If the window needs to be refreshed, that 1x1024 image is not re-sent. It is cached and can be re-used. That is a big difference between full-buffer approaches like VNC and even modern X.

FYI, FLTK works in pure X even today. The theme may include pixmaps, but they are used smartly as described above - nowhere is a complete image of the window drawn and then sent.

[pixo]

If the toolkits integrated webgl backend we could have universal network transparency.
You would then implement webgl interface into compositor or use browser.
But i dont know if its possible or how efficient it would be.

[ua=42]

Sending pixmaps does not mean it's not rendered client-side. Are you familiar with the common CSS technique of a gradient image? 1x1024 pixels image, drawn N times to create a gradient background. In X terms, that is both sending a pixmap and rending it client-side N times.

If the window needs to be refreshed, that 1x1024 image is not re-sent. It is cached and can be re-used. That is a big difference between full-buffer approaches like VNC and even modern X.

FYI, FLTK works in pure X even today. The theme may include pixmaps, but they are used smartly as described above - nowhere is a complete image of the window drawn and then sent.

That's the point of wayland enabling support for delta's and compression for remote applications. A good compression algorithm for video only records what has changed in-between frames, so if only a 20x20 pixel area changed, it will compress and send the data for that 20x20 area.

[Bbox]

FYI, FLTK works in pure X even today. The theme may include pixmaps, but they are used smartly as described above - nowhere is a complete image of the window drawn and then sent.

Great, so you can remote an 80's gradient desktop background 'smartly' and it kinda works well on a 90's network :P. What about window content, which makes up 90% of the screen in 3rd millenium apps when doing some real work. Who would remote a terminal or some gui buttons and textboxes over wayland protocol?

Tight integration of vnc approach with the compositor (or even wayland) is the best universal way that will always work. By sending just the (compressed) screen damage, it can cope with everything X-network-transparent even on slow networks. And on todays standard G-LAN you can easy do 30 fps.

When going over web, I found the best perfomance offered by apps which had their own remote connection, by installing special client software. Going that route, some support could be added to toolkits and/or rendering libs. Again complex rendering might not be possible on clients, but could be checked for to offer the most network-efficient way of remoting and even fall back to vnc if there is no client support. I also found remoting just the application to integrate on the local desktop to be the best way for my needs.

[curaga]

That's the point of wayland enabling support for delta's and compression for remote applications. A good compression algorithm for video only records what has changed in-between frames, so if only a 20x20 pixel area changed, it will compress and send the data for that 20x20 area.

It can indeed be adequate. Yet, there are a lot of cases where a video detection will do a lot worse than the app with knowledge.

Example: repeating gif animation. The video codec would detect image changes. The remoting app would instead upload all frames once, and then send commands to draw frame X.

[erendorn]

It can indeed be adequate. Yet, there are a lot of cases where a video detection will do a lot worse than the app with knowledge.

Example: repeating gif animation. The video codec would detect image changes. The remoting app would instead upload all frames once, and then send commands to draw frame X.

And there is a lot where video detection will do a lot better than the app with knowledge: anything animated and GPU rendered. I'll happily burn bandwidth for animated 20x20 icons for that.

[curaga]

Uh, no. The app with knowledge will always do better than a generic video detector.