DirectX9：present（）和实际屏幕更新之间的延迟

Question

我的问题是在DirectX9中调用当前方法与屏幕上显示的更新之间的延迟。

在Windows系统上，我有一个使用DirectX9打开的窗口并以一种简单的方式更新它（更改整个窗口的颜色，然后调用IDirect3DSwapChain9的当前方法）。在垂直空白间隔期间，我使用标志D3DPRESENT_DONOTWAIT调用交换链的当前方法。交换链只有一个缓冲区。 我还获得了外部测量，当我使用的CRT屏幕实际上通过连接到屏幕中心的光电二极管改变颜色时。我以亚毫秒的精度和延迟获得了这种测量结果。

我发现更改出现在调用present（）之后的第三次刷新中。因此，当我在垂直空白的末尾调用present（）时，就在屏幕刷新之前，在调用present（）之后，屏幕上的更改将正好显示为2 * screen_duration + 0.5 * refresh_duration。

我的问题很普遍：

• 我可以依赖这个延迟（第三次刷新中出现的变化）在不同系统上的相同程度......
• ......或者它随显示器而变化（不考虑LCD和LED显示器的响应时间）
• ...或使用显卡
• 是否存在影响此延迟的其他因素

另一个问题：

• 是否有人知道在DirectX9中确定屏幕上出现更改的方式（无需外部测量）

Answer 1

There's a lot of variables at play here, especially since DirectX 9 itself is legacy and is effectively emulated on modern versions of Windows.

You might want to read Accurately Profiling Direct3D API Calls (Direct3D 9), although that article doesn't directly address presentation.

On Windows Vista or later, once you call Present to flip the front and back buffers, it's passed off to the Desktop Windows Manager for composition and eventual display. There are a lot of factors at play here including GPU vendor, driver version, OS version, Windows settings, 3rd party driver 'value add' features, full-screen vs. windowed mode, etc.

In short: Your Mileage May Vary (YMMV) so don't expect your timings to generalize beyond your immediate setup.

If your application requires knowing exactly when present happens instead of just "best effort" as is more common, I recommend moving to DirectX9Ex, DirectX 11, or DirectX 12 and taking advantage of the DXGI frame statistics.

Answer 2

如果有人因此遇到类似的问题：我在调用present()后发现我的屏幕更新正好在第三次刷新时出现的原因。事实证明，默认情况下，Windows操作系统会在呈现它们之前排队3帧，因此第三次刷新时会出现更改。就目前而言，这只能是“固定的”。由Directx10（和Directx9Ex）开始的应用程序;对于Directx9及更早版本，必须使用显卡驱动程序或Windows注册表来减少此排队。