RFB (the protocol used for VNC) implements at its base level rectangle-based updates which can be used to send over just rectangle-bound differences between frames. It's just that some shoddy server implementations send over the entire screen at once without damagerect tracking.

There's also plenty of extensions, some proprietary some not, which allow for more advanced compression/optimization: https://en.wikipedia.org/wiki/RFB_protocol#Encoding_types

Windows RDP is a much better experience than basically everything else, it's not diffing a big jpeg of the screen like almost everything else does it sends more primitives to do more compositing on the client end. If the latency is low you often can't tell you're remote. You can actually work on it all day rather than just for doing odd bits of tech support. Plus it maps printers, audio etc.

+1 for Windows RDP. One thing Windows RDP excels at is working over low bandwidth connections. My remote desktop is in a rural area with very poor internet service -- uploads under 1 Mb/sec. With Win RDP I set the "Experience" to "56k Modem" (not joking) and it eliminates eye candy stuff like font smoothing and window animations, which is fine, at least I have a steady connection that works. I've tried other RDP programs and they always say "connection lost" due to insufficient bandwidth.

For VMs, I find RDP to be on par with SPICE (which is more of a qemu/libvirt thing). Both have support for device/drive mapping, I believe. That's both over ssh sessions (I know RDP has encryption, but I'd rather not trust it).

IIRC it hasn't worked like that since Windows 10. It's more or less h264. As due to Electron, QT, and UWP nothing draws those primitives anymore.

RDP itself in its earliest versions is just a windows GDI async RPC. Which is why its so fantastically fast/responsive on windows. And as of last time I mess with this, thats the way it still behaves for things like MS office, and basically anything that is older than a half dozen years or so, because they are still sitting on the win32 GDI.

But, yes your right if you have a "modern" application that is basically doing all the drawing on the CPU to a generic canvas with custom libraries none of that works, and RDP has to fall back to diffing and compressing. Which is really terrible on any number of fronts.

At that point you might as well just use VNC because the perf is going to be roughly the same.

Progress!

The ui of modern Office is React Native

I wrote a man-in-the-middle recording for RDP way back when. We did recording for both, RDP is much more sophisticated.

Besides using a TLS style encryption (VNC at the time had none). RDP tries as hard as possible to not just send bitmaps. It first shares what fonts it wants to use, then a cache of bitmaps from the previous session (for the wallpaper for example). When Windows move it doesn't send bitmap updates, it sends window updates and tells the client to paint a rect, then draw fonts, etc..

That said, it's a bear of a protocol with countless versions and "speed mode" hacks that bypass the layered protocol setup, tons of weird features, etc..

Interesting, is there software that still records RDP sessions? I'm not sure if Teams uses RDP or what, but I know it lets you record a call, whether there's screensharing or not.

This seems to do the same kind of thing. https://github.com/GoSecure/pyrdp

RDP is a crazy complex protocol, and you have options for pretty much everything.

On the graphics side, you can send over draw commands "draw the letter A here using this font", or you can send opengl calls, or you can send dumb bitmap updates. You can get the other end of the connection to do compositing ("blur this buffer and overlay it over that buffer with 50% transparency").

You can also get the remote end of the connection to decode videos - so when you hit play on an MP4 video inside an RDP connection, the actual video decoding gets done on the client not the server.

I've long been a huge fan of Xpra https://github.com/Xpra-org/xpra , both because of its "screen for X" original focus (though now it supports shadowing an existing session).

There was NoMachine / nx / freenx but it always seemed to be a weird animal to me, requiring installation as a separate unix user, at least at the time.

Windows has a special rendering mode for applications when RDP is being used to optimise the connection by redrawing as little as possible. It has the ability to dynamically switch between crisp, pixel accurate forward-chunked-GDI-draw-calls mode to a connection speed based compression level of an H.264/H.265 stream. There are also a bunch of extensions related to GPU acceleration.

If you use RDP on a Windows server with a consumer GPU, you van hack the Nvidia driver to make more NVENC streams available (they're capped in software) to run more RDP heads without overhead.

RDP also does sound forwarding, local drive forwarding, printer forwarding, and USB device forwarding (up to a point). It also supports a wide range of security features and authentication as security requirements have increased over the years, and has built-in support for bastion hosts/gateways.

One very interesting feature is the ability to RDP only specific applications rather than the desktop. Cassowary will let you "use Windows applications" by using a Windows VM and using RDP to run the applications on Linux as if they were running locally (Cassowary also automatically suspends the VM which is what sets it apart). It's a bit like X11 forwarding, except your local files and drives available without extra commands to set up reverse SSHFS mounts.

VNC is to RDP what telnet is to HTTP/3. The underlying concepts are the same, but the implementations have very different feature sets and advancements. Does VNC even support passwords longer than right characters yet? Last time I checked, VNC servers still truncated your password.

Being proprietary, RDP support on Linux is very limited in comparison. RDP clients like Remmina support a surprising amount of features, but on the server side things aren't as compatible. For example, connecting to xrdp works great from desktop clients, but the Microsoft client on Android is slow as hell.

I've also experienced buggy behaviour on Gnome when FreeRDP tries to render window borders in app mode. Window borders don't get drawn right and clicks seem to be shifted by it for some reason.

I don't blame the FreeRDP/xrdp developers for any bugs or problems because RDP is a terribly complex protocol with tons of features, but sadly Linux doesn't seem to have an implementation or alternative that compares to Windows and RDP together.

> VNC is to RDP what telnet is to HTTP/3. The underlying concepts are the same, but the implementations have very different feature sets and advancements.

I don't know a lot about http3. This comparison does not make a lot of sense to me with regards to http2. What changes have been made in http3 to make it conceptually close to telnet?

You set up a connection between two servers and exchange text. HTTP/3 does a boatload more than telnet, but in its core it's just sending text back and forth with some optional special tricks.

VNC and RDP both solve "log in to a remote computer", but RDP does a lot more than just sending images one way and sending HID input the other way.

normal slow doctor stuff... fine...

VNC is dog-slow compared to RDP. RDP is slow compared to xpra. What xpra does is sending a h.264 video stream (some other compression algos are also available). Also, xpra can forward the whole desktop as well as single applications. Far preferable to any kind of RDP server.

However, the xpra client is somewhat strange and inconsistent when it comes to CLI/UI behaviour.

RDP will also send a video stream depending on what's happening on screen. It'll try to detect the appropriate transfer mechanism as chunked screen updates increase and decrease in frequency, assuming both sides support the necessary protocol versions.

Video streams can be a real issue if you're working over a slow connection, especially when your application is using small text. RDP will handle remote GUIs much better, as low bitrates tend to make text unreadable.

Of course RDP also supports streaming individual applications.

Personally, I think RDP is undefeated at what it was designed for: controlling desktop GUI applications. On Linux, that's not the case, though, and xpra will provide a very good alternative.

However, I find very few good xpra clients outside of Linux distros. For example, when I look for xpra in Google Play, the first three options are Microsoft's RDP client, two X11 servers, and RealVNC. F-Droid lists nothing at all. I suppose u could try the HTML5 client but it's kind of a bummer. The situation seems to be the exact inverse of RDP: very good Linux server, difficult to use Windows clients on all other platforms.