Hacker News new | past | comments | ask | show | jobs | submit login
XRDP with H.264 codec brings immense performance boost (reddit.com)
84 points by DesktopECHO on Oct 28, 2023 | hide | past | favorite | 19 comments



If anyone on Windows would like to see what performance is like, I updated my WSL installer scripts to use this version of XRDP.

Ubuntu XFCE: https://github.com/DesktopECHO/xWSL

KDE Neon: https://github.com/DesktopECHO/kWSL

Kali: https://github.com/DesktopECHO/Kali-xRDP

These scripts will build a complete RDP-accessible Linux desktop environment in WSL. A GPU isn't needed to see a significant performance gain over 'stock' XRDP.


How does windows RDP work so well? From what I’ve seen it’s the best performing Remote Desktop but I always assumed some rendering happened client side?


Good old RDP sent the GDI calls directly. It also had fairly efficient bitmap caching. Then it got the H.264 stuff similar to what's mentioned here.

However in both cases I think the key reason RDP works so well is that it's very integrated in the stack.

I fiddled with FreeRDP server some 10 years ago, to see if I could improve performance. First off it ran on top of Xorg as effectively just another program. So getting a copy of the framebuffer was very CPU intensive, taking hundreds of milliseconds each time. Since this was before hardware H.264 encoding, it then had to do a delta pass to figure out the "damaged" regions, ie those needing an update. A full pass over the framebuffer comparing it with the previous framebuffer, very memory and CPU intensive. Then it could compress and send those regions to the client. The performance was very similar to good old VNC, ie horrible, so I expect it worked similarly.

Compare with good old RDP. It was integrated into the OS. It could send the draw calls to the client, or if needed, it could send bitmaps of regions. However if it had to do that, it already had the information of the damaged regions because Windows kept track of that anyway for redrawing purposes, so it didn't need to do any comparison pass like to find the damaged regions, and it could capture the draw calls from the applications, so no need to do a full framebuffer dump.

I really think Linux desktops like KDE and similar need to go a similar route if they ever want to get a decent competitor to Windows RDP. Remote Desktop needs to be designed into the solution, from the lower levels and up, not just tacked on top afterwards.


VNC and the like are basically just transmitting the framebuffer to the client. There are some extensions for stuff like better support for video though.

RDP works a bit differently:

https://learn.microsoft.com/en-us/windows/win32/termserv/rem...

On the server, RDP uses its own video driver to render display output by constructing the rendering information into network packets by using RDP protocol and sending them over the network to the client. On the client, RDP receives rendering data and interprets the packets into corresponding Microsoft Windows graphics device interface (GDI) API calls.

RDP supports various mechanisms to reduce the amount of data transmitted over a network connection. Mechanisms include data compression, persistent caching of bitmaps, and caching of glyphs and fragments in RAM. The persistent bitmap cache can provide a substantial improvement in performance over low-bandwidth connections, especially when running applications that make extensive use of large bitmaps.

https://learn.microsoft.com/en-us/azure/virtual-desktop/rdp-...

To reduce the amount of data transferred over the network, RDP uses the combination of multiple techniques, including but not limited to - Frame rate optimizations - Screen content classification - Content-specific codecs - Progressive image encoding - Client-side caching

Remote Desktop Protocol is a modern protocol designed to adjust to the changing network conditions dynamically. Instead of using the hard limits on bandwidth utilization, RDP uses continuous network detection that actively monitors available network bandwidth and packet round-trip time. Based on the findings, RDP dynamically selects the graphic encoding options and allocates bandwidth for device redirection and other virtual channels. This technology allows RDP to use the full network pipe when available and rapidly back off when the network is needed for something else. RDP detects that and adjusts image quality, frame rate, or compression algorithms if other applications request the network.


I’ve just spent the last two weekends playing woth xrdp on fedora as a server and usinng the ipad as a client… and I’m very satisfied.

Hopefully we’ll see these xrdp changes in fedora soon!


How much does this speed up sessions over higher latency connections I wonder? I have been looking for RDP performance similar to that of Windows on Linux, but up until now it has been semi slow over WANs.


Very well. Assuming you have identical CPUs (say Intel with QuickSync) The performance constrains are really more dependent the desktop environment you choose (I have good results with GNOME on a LAN but LXDE works better in Azure since it has less decoration).


how does cpu play into this?

encoding and decoding h264 should be available on skylake and beyond


CPU overhead is minimal if you use xorgxrdp-glamor on an Intel iGPU. If you don’t use glamor or don’t have an iGPU then you get llvmpipe rendering for graphics and CPU H.264 encoding for the RDP stream (but RDP will seldom negotiate H.264 in that scenario)


I wonder how close this gets to Parsec performance.


It is very good, and much less hassle than Parsec to setup today.

I’ve been doing this for a long while now, here’s one of the most complete writeups I did last year: https://taoofmac.com/space/blog/2022/10/23/1700

TL;DR: install xorgxrdp-glamor and make sure you are using the Xorg session in xrdp-sesman.

It is almost as fast as GPU-accelerated RDP in Windows, although that relies on deeper acceleration support (I have notes on that here: https://taoofmac.com/space/protocols/rdp )

A big concern I have right now is that Wayland is nowhere near as useful for multi-user RDP access (it doesn’t even seem to support offscreen GPU accelerated rendering, but that may just be my testing on Fedora).


I believe your writeup is about enabling Glamor; it does not do anything to enable the H.264 "Clear Codec" branch of XRDP.

Apologies in advance if I'm wrong here, please correct me if I'm mistaken :)


That is already done in Fedora as far as I can tell - I have a couple of manually-built servers and can’t notice a difference.

But I have many more posts on RDP (check the footer back links)


I don't see anything with regards to inclusion of the Clear Codec (RDP8.1 + H.264) in Fedora builds.

If there is evidence indicating this is actually the case, please let me know.


Another is the availability of a good GPU-accelerated client, but I can’t seem to get the Xrdp SDL client to build and work right either.


freerdp on debian bookworm has h264 support


That's client side. FreeRDP needs H.264 libraries to work with this branch of XRDP. Apparently, Ubuntu and variants do not include this in their FreeRDP builds, good to know it's in Debian though.

(MSTSC.EXE and the official macOS RDP client already have H.264 support built-in)


Off topic, and apologies

But is there a recommended client for chromebooks?


I have to use remote desktop on a daily basis.

So for the past few years, originally it was anydesk. They enshittified their free offering so I shipped with rustdesk for the past 2 years.

Connection issues so found it can be run over lan or sdwan without connecting to a relay so direct connection. Its been bullet proof connecting since.

Over the past few weeks, found about aspia.org which again works locally.

Remmina also works but problems.

I'm running KDE neon with Wayland.

Biggest problems.

Alt tab and many shortcuts escape to local and not remote device. That gets annoying fast.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: