Enable h/w acceleration in RDP

[vatsan-madhavan]

wpf/src/Microsoft.DotNet.Wpf/src/WpfGfx/core/common/display.cpp

Lines 2128 to 2134 in e7cad62

	if (m_rgpDisplays.GetCount() == 0 || m_fNonLocalDevicePresent)
	{
	//
	// No display - no acceleration
	//
	caps = GetNoHardwareAccelerationCaps();

Remove that check for m_fNonLocalDevicePresent and DirectX h/w acceleration in RDP will start working.

In general, the overall role of m_fNonLocalDevicePresent may have to be re-evaluated and updated. <>

This limitation (is s/w rendering in RDP) is no longer needed in WDDM driver model, though it made sense historically when XPDM drivers were in the mix in the ecosystem for .NET Framework.

Stretch goal: Prove this works well and is safe in .NET 5 and then port the change to .NET 4.8. All the remote working software devs who use Visual Studio over RDP would love the improvement.

/cc @fabiant3 , @SamBent - I’d be happy to contribute if you are open to take this change. Not sure whether the timing is right wrt .NET 5 schedule etc.

[fabiant3]

@vatsan-madhavan - appreciate the help and we should look at doing this post NET5.

[SKARFX]

Hi! We are using DirectX in our application (over RDP). How long to wait for a solution for .NET 4.8?

[omariom]

[JamieM942]

Our company would also like this enhancement request. I find it weird how RDP has never done this yet Citrix’s protocol can achieve this.

[vatsan-madhavan]

It's been a couple of years since I opened original issue, but I distinctly remember doing the analysis and the fix was indeed a simple one and I don't recall being worried about potential regressions. In the past, I've done this analysis more than once (about 2-3 years prior to opening the issue, IIRC) and I concluded the same thing - that the fix was both simple and not likely to cause breakages. The best way to be sure is, of course, to run regression tests within RDP.

For .NET, I don't think that an extra defensive quirk is called for. If you port this to .NET Framework, then you should definitely quirk it (I added some plumbing in the renderer to enable support for the NET Framework's AppContext quirking infrastructure a long time ago - so these sorts of fixes can be quirked cleanly I believe).