Yeah, we at Proxmox are actually evaluating such things, and we hope that IronRDP and QEMU display [0] can be part of a stack that replaces SPICE in the long term, but it will need a bit more time to see how this play out and what exact role it can play in Proxmox VE.
Another experiment is to see if we can add a more modern video encoding to QEMU, as the recently released noVNC 1.6 gained support for H.264 [1]; albeit we naturally would prefer something more open like AV1.
AV1 eliminates MPEG licensing issues, but encoding in hardware is even more limited. Also, AV1 is great for encode-once use cases (e.g. YouTube) since it's heavily geared towards reducing bandwidth requirements vs. encode speed. It's workable for real-time streaming in the lowest settings, but H.264 is still better overall.
Modern CPUs more often have the building blocks included for video encoding, and getting one of those, or a dedicated GPU, probably makes sense if the Users/VMs workload depends on graphical output.
That said, you're definitively also right that it won't be a win for every use case on every hardware, so definitively something to look at more closely, and if it really is worse than the status quo on systems without dedicate GPU and where the CPU has now HW accelleration than the status quo, which I doubt, then adding an opt-out will definitivelys make sense.
It's been around for six years?
Seems like enough to say "let's try it out, see how things go, I bet if we start working with it, things will accelerate rapidly" to me.
We started evaluation a few weeks ago in combination with the QEMU display work, which is still experimental and was initially announced mid-January this year, so we're still at the POC stage and thus this work will be a bit more time. I did nowhere say that IronRDP will need more time.
And FWIW, without an integrated approach RDP gains you almost nothing over plain VNC if you have only the reduced interfaces and access from outside the VM, so using something like IronRDP earlier on its own would not have gained us much besides an extra component to maintain, that's why we did not checked out integration earlier.
I'll relay your invitation to the persons mainly doing the evaluation. And good to hear that QOI image coded is getting further adoption.
A hypervisor just sees the video output from the VM and has no knowledge of the underlying GUI's state, so even with RDP it won't be able to do much better than stream compressed bitmaps.
Modern RDP also has the option to turn (parts of) the screen into a simple h.264 stream so the connection doesn't die when you open up a web page with an animated background.
So -
* VNC: Low overhead / Low fidelity
* RDP (and other remote desktop protocols, e.g. Frame Remoting Protocol, Horizon Blast, Citrix ICA/HDX): Higher overhead / High fidelity
* VNC (and other non-RDP solutions like TeamViewer etc): fully independent application, does not change how Windows works because it's effectively just an interactive screen recorder running for your user account.
* RDP: is an actual Windows remote user session that hijacks the computer (so a local user can't see what's happening) and hooks directly into Windows with its own device bindings and login properties (e.g, you can't just click start -> shut down, instead you need to command-line your way to victory).
If you want to remote into a machine that's playing audio without interfering with that, RDP is flat out not an option. Even if you pick "leave audio on the remote", the fact that RPD forces windows to use a different audio device is enough to interfere with playback.
RDP in Windows happens to be implemented using some fancy tricks that make it a much better OS for remote work than any Linux distro, but that doesn't mean that's the only possible implementation. Whatever logic can be used to detect block updates in VNC works just as well over RDP. Audio over RDP also works fine on both Windows and Linux so I don't see what the problem would be anywhere else.
As for the shutdown thing, Linux seems to do that too. Makes sense if you use your computer as a terminal server, I guess. I don't reboot my computer over RDP enough to care, really. Still, that's just an implementation choice, nothing to do with the protocol itself.
RDP will run without issue over a 56k modem in a low color mode to an RDP Host.
While RDP may run okay on 56k with low color mode for some use cases (e.g. simple Windows admin), it requires significantly more bandwidth and compute overhead (either CPU or GPU) for other more advanced use-cases (e.g. video editing, CAD etc.)
"In the virtual network computing (VNC) system, server machines supply not only applications and data but also an entire desktop environment that can be accessed from any Internet-connected machine using a simple software NC." -- https://www.cl.cam.ac.uk/research/dtg/attarchive/pub/docs/at... (1998)
VNC was designed for remote desktop use. All the other streaming features came along later. I don't see why RDP would make for a worse choice here, other than that Windows VM integration would make for an better solution.
RDP used to be far inferior because it was proprietary Microsoft stuff with buggy open source clients and undocumented servers that kept changing stuff around. These days, open source RDP server software is actually quite solid. I don't know if Gnome/KDE leverage the partial update mechanism that makes RDP so useful on Windows (doesn't seem to seeing the performance I'm getting out of VMs), but I find RDP to be a lot more useful for interactive desktop streams than VNC.
I guess that would be something for the wayland compositor to manage. Maybe a wayland compositor that is also an RDP server? or maybe they're all like that already?