Wayland just realized that remoting is not an operation that has to be integrated into the protocol. It can be done by third-party applications better through proper compression techniques.
If you want to make a separate window manager, it is likely that the result is going to be incompatible with most existing clients. But this seems par for the course for almost every Wayland extension so far (see Gnome...).
And beside gnome and kde there is a third big group of wayland compositors based on wlroots which does support some form of common set of extensions not in core, effectively making you write only the wm part.
Because this prevents creation of a separate window manager program. You can do all of this with the core protocol in X11. You can't do any of it in Wayland almost by design. The entire idea of a client getting simultaneous access to the objects of another client is not in the protocol. You cannot render in another process surface. You cannot even iterate over its windows! The role of the compositor is hardcoded in the protocol design.
The closest thing you can do is to write some type of modular compositor which speaks _yet another_ protocol with the window manager module (or even exists within the same process). But this is not like in X11, where you plug new things (e.g. a new WM, a new pager) without having to restart the X server, much less having to change it.
see how it looks: https://streamable.com/t9foij
RDP also sends draw calls, and as such cannot be compared to VNC or similar. It's not even a remotely close comparison in terms of fluidity. I haven't compared it to Qt over X11, but I wouldn't be surprised if RDP wins over an internet link.
The lack of a proper RDP alternative is the primary reason I don't use Linux as my main driver. I keep checking every 12 months or so, but alas.
on linux with native linux apps ?
Point was that RDP in its natural environment can forward draw calls, and as such is more like X than VNC.
RDP is to X as PowerShell is to bash: better than the Unix standard thing because it isn't weighed down by Unix community baggage.
Also, you were right on RDP, but something less is more.
If any, I prefer plan9/9front's drawterm/cpu which runs circles over Unix/Linux VNC and RDP. By a huge mile.
And 9p>>>>>>>> NFS/SMB. For anything else, use FS' permissions FFS, and choose wisely what you share.
How can this [1] code possibly be faster than modern hardware accelerated blitting? I don't see a line of SIMD in there.
[1]: https://github.com/9fans/drawterm/blob/master/libmemdraw/dra...
What you could do today with PSH and iPython Perl folks did that before with far more modules thanks to CPAN and C bindings.
I tried steamlink on the same network to put games on my TV, and it is barely useable with absolutely horrendous image compression (got a GTX1080 GPU so that's likely not the culprit)