|
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. |