> It is another block pusher as far as I understand.
While that is the most basic thing RDP allows for[1], it also supports sending GDI draw calls[2] which is more like X-forwarding.
It also hooks into the stack at a lower layer than VNC and friends so when sending bitmap block updates it has the dirty area information directly available, and doesn't have to do a frame-by-frame delta to recover that information. This is a huge CPU hog from my experience when I did some work on the FreeRDP server component years ago.
It also supports using UDP[3] with forward error correction to improve performance over WANs.
Aha I had no idea it worked like that, with the GDI calls. That makes sense. There is definitely a performance advantage I've seen that's not matched when you run RDP on Linux. I assumed this was because of implementation issues but of course Linux doesn't use GDI so this makes sense, so it has to revert to block pushing. Thanks for pointing it out.
While that is the most basic thing RDP allows for[1], it also supports sending GDI draw calls[2] which is more like X-forwarding.
It also hooks into the stack at a lower layer than VNC and friends so when sending bitmap block updates it has the dirty area information directly available, and doesn't have to do a frame-by-frame delta to recover that information. This is a huge CPU hog from my experience when I did some work on the FreeRDP server component years ago.
It also supports using UDP[3] with forward error correction to improve performance over WANs.
[1]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...
[2]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...
[3]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...