And we do have hardware encoding / decoding. The latency is quite reasonable, like 15ms in total, so modern solutions like parsec work for any app, including games and CAD.
That stuff was just appearing when I last worked on an RDP client for a mobile platform. At the time, it depended on the application/client region and the bandwidth/capability requests from the client. AKA, it would kick in for an application that was just dumping a predrawn buffer but not for applications that were still using the Win32 API extensively unless there were additional graphical operations going on (e.g., transparent windows).
And that is part of the fun of RDP, it has an immense number of different ways of accomplishing the end goal, and newer methods were being added to compensate for the way applications themselves were being written while the older ones remained. It was a long road of dealing with edge cases, with certain applications not rendering properly.
AKA, use a 3rd party library to draw all the GUI widgets and windows didn't have any alternative but to come up with a better way to compress and send those updates. And the last time I ran an RDP client to Windows, this stuff was still visible; older win32 applications were fast/responsive, and things like Firefox would just chug every time it hit a web page that was doing any kind of dynamic content (think scrolling an ad).
https://techcommunity.microsoft.com/t5/security-compliance-a...
And we do have hardware encoding / decoding. The latency is quite reasonable, like 15ms in total, so modern solutions like parsec work for any app, including games and CAD.