Re: [Bloat] DSLReports Speed Test doesn't like Remote Desktop

[Jonathan Morton <chromatix99@gmail.com>]

> On 28 Aug, 2021, at 10:36 pm, Michael Richardson <mcr@sandelman.ca> wrote:
> 
> RDP (specifically with Windows as the desktop) is integrated into the display
> pipeline such that it effectively never loses frames.  The results of an
> (e.g.) Excel redraw over a slow link can be spectactically stupid with every
> cell being drawn each time it is "re"-computed.  The result is that the
> application itself is blocked when the RDP frames are being generated.
> 
> I/we observed this a decade ago when building virtual desktop infrastructure.
> There was a Linux Xrdp server (via a bunch of patches that didn't survive)
> that was more screen-scraper.  VNC has always screen scraped the pixels, so it
> "naturally" skips the intermediate frames when the application draws faster
> than then remote desktop protocol can keep up.
> 
> I thought that there were patches to RDP to make this better, but I never
> confirmed this.

Funnily enough, I was actually in the VNC community for a while, having written a functioning server for Classic MacOS, so I'm familiar with this dilemma.  Due to some quirks of Classic MacOS, it was often necessary to do the screen-scraping, encoding and socket transmissions at interrupt time, and I had to limit the amount of data generated at any given time so that it didn't block on a full buffer - which could lock *everything* up.

My experience of modern browser rendering pipelines is that they do everything in backbuffers, then blit them to the screen wholesale.  This *should* be quite efficient for an RDP to handle, so long as it excludes areas that were unchanged on consecutive blits.  But it's also possible for it to pick up drawing to background tabs, and only after much CPU effort determine that nothing visibly changed.

At any rate, the original problem turned out to be something else entirely.

 - Jonathan Morton