DXGI Desktop Duplication API并非“超高速GPU级”采集，其本质是绕过CPU拷贝而非加速GPU；LastPresentTime跳变或为0主因是DWM未提交新帧，需用有限超时+返回值检查+本地高精度计时替代依赖该字段。
不能靠 DXGI Desktop Duplication API 实现“超高速 GPU 级”采集——它本身不加速，只是绕过 CPU 拷贝；真瓶颈在 GPU 解码、内存带宽和帧同步逻辑上。
为什么 IDXGIOutputDuplication::AcquireNextFrame 返回的 DXGI_OUTDUPL_FRAME_INFO 里 LastPresentTime 经常跳变或为 0
这个字段依赖桌面窗口管理器（DWM）是否实际提交了新帧。常见原因包括：
- DWM 处于“空闲状态”（比如桌面无动画、无窗口刷新），会跳过 Present，
LastPresentTime不更新 - 应用使用了
SetThreadExecutionState(ES_DISPLAY_REQUIRED)但未触发重绘，DWM 不生成新帧 - 多显示器不同刷新率下，
AcquireNextFrame可能跨输出等待，LastPresentTime来自非目标屏 - 调用时传了
INFINITE超时但没检查返回值——WAIT_TIMEOUT时FrameInfo内容未定义，LastPresentTime是垃圾值
实操建议：永远用有限超时（如 16 ms），检查返回值是否为 WAIT_OBJECT_0，否则跳过本次帧处理；时间戳应以 QueryPerformanceCounter 本地采样为主，仅把 LastPresentTime 当作辅助参考。
AcquireNextFrame 后必须调用 ReleaseFrame，但什么时候调用最安全
不是“用完纹理就立刻释放”，而是必须等所有 GPU 操作（Copy、Map、编码）全部完成后再调用。否则会出现：
立即学习“C++免费学习笔记（深入）”；
- GPU 正在读取该帧，
ReleaseFrame导致下一帧采集失败（DXGI_ERROR_ACCESS_LOST） - 编码器还在从 staging buffer 读数据，提前释放导致画面撕裂或黑块
- 多线程场景下，采集线程释放了帧，但编码线程还没完成
Map，触发访问冲突
实操建议：用 ID3D11DeviceContext::Flush + IDXGIKeyedMutex::AcquireSync 做显式同步；更可靠的是在编码线程完成 Unmap 后，由该线程通知采集线程执行 ReleaseFrame；避免在采集线程中直接调用 ReleaseFrame。
如何避免 DXGI_ERROR_WAIT_TIMEOUT 和频繁丢帧
超时不是因为性能差，而是 DWM 帧节奏与采集节奏不匹配。关键点在于：
- 不要每 1ms 调用一次
AcquireNextFrame——这会让 DXGI 队列阻塞，反而加剧丢帧 - 启用垂直同步（
DXGI_PRESENT_VSYNC）对采集无意义，DWM 已控制合成时机；采集端应主动适配 DWM 的 Present 频率 - 用
DXGI_OUTDUPL_FLAG_DISABLE_ACCESSIBLE_SURFACE创建 duplication 对象可减少锁竞争，但会禁用部分调试能力 - 真正有效的降丢帧策略是：缓存最多 2 帧（一个正在编码，一个刚采集），并用
GetDesc检查当前输出刷新率，动态调整采集间隔（如 60Hz 下设为 15–17ms）
示例节选：
UINT timeoutMs = (1000 + refreshRateHz / 2) / refreshRateHz; // 四舍五入到毫秒比固定 16ms 更鲁棒。
staging texture 的 Map 性能为何比预期差很多
根本问题在于：即使用了 D3D11_CPU_ACCESS_READ，Map 仍可能触发 GPU stall——特别是当 staging texture 还在被 GPU 写入时。Windows 10 1809+ 引入了 DXGI_MAP_FLAG_DO_NOT_WAIT，但支持有限。
- 错误做法：每次
AcquireNextFrame后都Map+memcpy到系统内存 → 高延迟、高 CPU 占用 - 正确路径：用
ID3D11DeviceContext::CopySubresourceRegion把 duplication texture 拷到 staging texture，再异步Map；或直接用ID3D11VideoProcessor输出到 NV12 staging texture，供编码器零拷贝接入 - 关键配置：staging texture 必须用
D3D11_USAGE_STAGING+D3D11_CPU_ACCESS_READ，且BindFlags = 0；任何其他 flag（如SHADER_RESOURCE）都会让 Map 失败或变慢
最容易被忽略的一点：CopySubresourceRegion 后必须调用 Flush 或插入 Signal/Fence，否则后续 Map 可能拿到旧数据——这不是 bug，是 GPU 异步执行的本质决定的。
