我完全理解你的困扰——切换到软件渲染虽然能让程序跑起来，但性能损失实在让人头疼。既然客户端和服务器都运行Windows 10 1903，且硬件本身支持RDP硬件加速，咱们可以从以下几个方向排查解决：

1. 先搞定系统级的远程桌面硬件加速配置 #

这是最基础的前提，很多时候问题就出在这里：

• 服务器端配置：
  • 打开本地组策略编辑器（gpedit.msc），导航到计算机配置 > 管理模板 > Windows组件 > 远程桌面服务 > 远程桌面会话主机 > 远程会话环境
  • 启用「使用硬件图形适配器进行所有远程桌面服务会话」策略，确保远程会话优先调用硬件GPU
  • 同时检查「配置远程桌面连接的硬件图形」策略，设置为「允许」即可
• 客户端配置：
  • 打开远程桌面连接（mstsc.exe），点击「显示选项」→「体验」标签
  • 勾选「桌面组合」（Windows 10 1903里这个选项对应远程FX硬件加速支持），并把体验级别设为「LAN (10 Mbps 或更高)」以上

2. 优化D3D11设备的创建参数 #

针对WPF D3DImage和远程会话的兼容性，调整设备创建逻辑：

• 创建ID3D11Device时，必须加上D3D11_CREATE_DEVICE_BGRA_SUPPORT标志——这是WPF D3DImage要求的格式支持，同时也是远程会话硬件加速的必要条件
• 保持驱动类型为D3D_DRIVER_TYPE_HARDWARE，功能级别指定D3D_FEATURE_LEVEL_11_0，不要回退到WARP
• 参考代码片段：

  D3D11CreateDevice(
      nullptr,
      D3D_DRIVER_TYPE_HARDWARE,
      nullptr,
      D3D11_CREATE_DEVICE_BGRA_SUPPORT | D3D11_CREATE_DEVICE_DEBUG, // Debug可选，用于验证
      &featureLevels,
      1,
      D3D11_SDK_VERSION,
      &pDevice,
      &featureLevel,
      &pImmediateContext
  );
  

3. 正确处理IsFrontBufferAvailableChanged事件 #

别直接忽略这个事件，要适配远程会话的环境变化：

• 当IsFrontBufferAvailable变为false时，暂停渲染循环并释放当前后台缓冲区；当变回true时，重新初始化D3DImage的后台缓冲区再恢复渲染
• 在远程会话启动时，延迟1-2秒初始化D3D设备和D3DImage——远程桌面的图形环境需要一点时间加载完成，过早初始化容易导致前端缓冲区检测异常

4. 验证硬件加速是否真的生效 #

可以通过这些方式确认配置是否到位：

• 在远程会话里运行dxdiag.exe，切换到「显示」选项卡，检查是否显示「远程桌面图形硬件加速已启用」
• 在程序里加日志，输出当前D3D设备的驱动类型（通过ID3D11Device::GetDriverType）和功能级别，确保确实在使用硬件设备
• 关闭验证层后，观察IsFrontBufferAvailable是否能稳定保持true——配置正确的话，这个状态不会持续为false

5. 恢复SetBackBuffer的硬件模式 #

等以上配置都调整好后，把SetBackBuffer的最后一个参数改回false（禁用软件渲染），此时WPF会通过RDP协议把D3D11的硬件渲染结果重定向到客户端，性能就能回到正常水平了。

最后补充个小提示：确保服务器和客户端的显卡驱动都是最新版本——部分旧驱动可能存在远程桌面硬件加速的兼容性问题，更新后能解决不少潜在bug。

内容的提问来源于stack exchange，提问作者Soonts