3 ms·

> The performance is just insanely good, It's still artificially capped to a really awkward framerate (maybe 24fps or ~32fps?), even today.

rcarmo 2y ago
You can set that to 60fps - https://taoofmac.com/space/protocols/rdp https://taoofmac.com/space/protocols/rdp
- DaiPlusPlus 2y ago
  That article instructs readers to use H.264 rendering and to set DWMFRAMEINTERVAL - thing is, DWMFRAMEINTERVAL is a host-side parameter and apparently all it does is set an upper-limit on the possible refresh rate [1], rather than force the entire RDP system (client and server) to run at a specific frane-rate. This also conflicts with a personal experience of mine: possibly around 2007-2009 I remember using a FOSS RDP client meant for Linux but ported to Windows for some reason, and I preferred using it to connect to a shared WS2003 TermSrv box on the LAN because it sure felt like 60fps, despite everything else wrong with a barely-complete Win32 port (I don’t think they even used MINGW; mad lads…). It was my own TermSrv box and I know I didn’t do anything server-side to make it work so buttery-smooth. …which tells me that the compromised user-experience caused by the artificially capped frane-rate of the RDP session is entirely at the direction of the client, not the server. But that was… 15+ years ago (…fuck), it’s possible the protocol has changed and maybe it’s something both host and client negotiate, but clearly its possible and clearly someone in the Windows Server group at MSFT enjoys cinema too much because they seem to think 24fps is good enough for everyone. Also, when you use H.264 in RDP, it defaults to 4:2:0 chroma subsampling[2] which is going to ruin fine-details and make text ugly if not unreadable - there’s a reason we use H.264 for movies but not text documents. I remember around 2013 when a bunch of competing remote-access companies all launched hardware-accelerated-video-based remote-desktop products and being impressed with how they handle remote-Netflix over a pre-LTE mobile tether, but reeling and gasping to throw-up after their aggressive codec motion-estimation, subsampling, and YUV colorspace absolutely butchered a 100% zoom Word document with ClearType enabled. Using the system instilled oneself with a strong discipline against ever moving or resizing a window on the desktop, lest the smears of low-bitrate macroblocks start to appear, warning you the text-on-screen is about to become painfully unreadable for the next few seconds while you curse the DSL connection you’re still forced to use because your apartment complex’s HOA got a sweet deal on satellite TV from the incumbent telco by blocking the local cableco, with their sweet sweet DOCSIS 4, from adding service to the building and I’m done. [1] https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/frame-rate-limited-to-30-fps#setting-frame-rates https://learn.microsoft.com/en-us/troubleshoot/windows-serve... [2] https://learn.microsoft.com/en-us/azure/virtual-desktop/graphics-encoding#chroma-subsampling-support-for-420-and-444 https://learn.microsoft.com/en-us/azure/virtual-desktop/grap...

rcarmo 2y ago

You can set that to 60fps - https://taoofmac.com/space/protocols/rdp https://taoofmac.com/space/protocols/rdp

DaiPlusPlus 2y ago
That article instructs readers to use H.264 rendering and to set DWMFRAMEINTERVAL - thing is, DWMFRAMEINTERVAL is a host-side parameter and apparently all it does is set an upper-limit on the possible refresh rate [1], rather than force the entire RDP system (client and server) to run at a specific frane-rate. This also conflicts with a personal experience of mine: possibly around 2007-2009 I remember using a FOSS RDP client meant for Linux but ported to Windows for some reason, and I preferred using it to connect to a shared WS2003 TermSrv box on the LAN because it sure felt like 60fps, despite everything else wrong with a barely-complete Win32 port (I don’t think they even used MINGW; mad lads…). It was my own TermSrv box and I know I didn’t do anything server-side to make it work so buttery-smooth. …which tells me that the compromised user-experience caused by the artificially capped frane-rate of the RDP session is entirely at the direction of the client, not the server. But that was… 15+ years ago (…fuck), it’s possible the protocol has changed and maybe it’s something both host and client negotiate, but clearly its possible and clearly someone in the Windows Server group at MSFT enjoys cinema too much because they seem to think 24fps is good enough for everyone. Also, when you use H.264 in RDP, it defaults to 4:2:0 chroma subsampling[2] which is going to ruin fine-details and make text ugly if not unreadable - there’s a reason we use H.264 for movies but not text documents. I remember around 2013 when a bunch of competing remote-access companies all launched hardware-accelerated-video-based remote-desktop products and being impressed with how they handle remote-Netflix over a pre-LTE mobile tether, but reeling and gasping to throw-up after their aggressive codec motion-estimation, subsampling, and YUV colorspace absolutely butchered a 100% zoom Word document with ClearType enabled. Using the system instilled oneself with a strong discipline against ever moving or resizing a window on the desktop, lest the smears of low-bitrate macroblocks start to appear, warning you the text-on-screen is about to become painfully unreadable for the next few seconds while you curse the DSL connection you’re still forced to use because your apartment complex’s HOA got a sweet deal on satellite TV from the incumbent telco by blocking the local cableco, with their sweet sweet DOCSIS 4, from adding service to the building and I’m done. [1] https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/frame-rate-limited-to-30-fps#setting-frame-rates https://learn.microsoft.com/en-us/troubleshoot/windows-serve... [2] https://learn.microsoft.com/en-us/azure/virtual-desktop/graphics-encoding#chroma-subsampling-support-for-420-and-444 https://learn.microsoft.com/en-us/azure/virtual-desktop/grap...