直线运动卡顿

我创建了简单的、与帧无关的、可变时间步长的线性运动Direct3D9 using ID3DXSprite。大多数用户无法注意到它，但在某些（包括我的）计算机上它经常发生，有时甚至会很卡顿。

• 口吃发生于VSync启用和禁用。

• 我发现同样的情况发生在OpenGL渲染器。

• 它不是浮点问题。

• 似乎问题只存在于AERO Transparent Glass窗口模式（在全屏、无边框全屏窗口或禁用 Aero 的情况下很好或至少不太明显），当窗口失去焦点时更糟。

EDIT:

即使发生卡顿，帧增量时间也不会超出 16 .. 17 毫秒的范围。

似乎我的帧增量时间测量日志代码被窃听了。我现在修好了。

• 通常启用垂直同步的帧渲染时间为 17 毫秒，但有时（可能发生卡顿时）它会跳至 25-30 毫秒。

（我只在应用程序退出时转储日志一次，而不是在运行、渲染时转储日志，因此它不会影响性能）

    device->Clear(0, 0, D3DCLEAR_TARGET, D3DCOLOR_ARGB(255, 255, 255, 255), 0, 0);

    device->BeginScene();

    sprite->Begin(D3DXSPRITE_ALPHABLEND);

    QueryPerformanceCounter(&counter);

    float time = counter.QuadPart / (float) frequency.QuadPart;

    float deltaTime = time - currentTime;

    currentTime = time;

    position.x += velocity * deltaTime;

    if (position.x > 640)
        velocity = -250;
    else if (position.x < 0)
        velocity = 250;

    position.x = (int) position.x;

    sprite->Draw(texture, 0, 0, &position, D3DCOLOR_ARGB(255, 255, 255, 255));

    sprite->End();

    device->EndScene();

    device->Present(0, 0, 0, 0);

感谢 Eduard Witch 和 Ben Voigt 修复了计时器（尽管它没有解决最初的问题）

float time()
{
    static LARGE_INTEGER start = {0};
    static LARGE_INTEGER frequency;

    if (start.QuadPart == 0)
    {
        QueryPerformanceFrequency(&frequency);
        QueryPerformanceCounter(&start);
    }

    LARGE_INTEGER counter;

    QueryPerformanceCounter(&counter);

    return (float) ((counter.QuadPart - start.QuadPart) / (double) frequency.QuadPart);
}

EDIT #2:

到目前为止我尝试了三种更新方法：

1）可变时间步长

    x += velocity * deltaTime;

2）固定时间步长

    x += 4;

3）固定时间步长+插值

    accumulator += deltaTime;

    float updateTime = 0.001f;

    while (accumulator > updateTime)
    {
        previousX = x;

        x += velocity * updateTime;

        accumulator -= updateTime;
    }

    float alpha = accumulator / updateTime;

    float interpolatedX = x * alpha + previousX * (1 - alpha);

所有方法的工作原理几乎相同，固定时间步长看起来更好，但它并不是一个依赖于帧速率的选项，并且它不能完全解决问题（仍然很少偶尔跳跃（口吃））。

到目前为止禁用AERO Transparent Glass或者全屏显示只是重大的积极变化。

我在用NVIDIA最新驱动程序GeForce 332.21 Driver and Windows 7 x64 Ultimate.

解决方案的一部分是一个简单的精度数据类型问题。将速度计算换成常数，您将看到极其平滑的运动。分析计算表明您正在存储结果QueryPerformanceCounter()在浮子内。QueryPerformanceCounter()返回一个在我的计算机上看起来像这样的数字：724032629776。这个数字至少需要5个字节来存储。曾几何时float使用 4 个字节（实际数字仅使用 24 位）来存储值。因此，当您转换结果时，精度会丢失QueryPerformanceCounter() to float。有时这会导致deltaTime零导致口吃。

这部分解释了为什么某些用户没有遇到此问题。这一切都取决于结果是否QueryPerformanceCounter()确实适合float.

这部分问题的解决方案是：使用double（或者正如 Ben Voigt 建议的那样：存储初始性能计数器，并在转换为之前从新值中减去该计数器float。这至少会给你更多的空间，但最终可能会达到float当应用程序运行很长时间（取决于性能计数器的增长速度）时，再次分辨率限制。）

解决这个问题后，卡顿现象减少了很多，但并没有完全消失。分析运行时行为表明，偶尔会跳过一帧。应用程序 GPU 命令缓冲区被刷新Present但当前命令保留在应用程序上下文队列中，直到下一个垂直同步（即使Present在 vsync (14ms) 之前很久就被调用了。进一步分析表明，后台进程 (f.lux) 告诉系统偶尔设置伽玛斜坡。该命令要求完整的 GPU 队列在执行之前耗尽。可能是为了避免副作用。此 GPU 刷新是在“当前”命令移至 GPU 队列之前启动的。系统会阻塞视频调度，直到 GPU 耗尽。这需要直到下一个垂直同步。因此当前数据包直到下一帧才移至 GPU 队列。这样做的明显效果是：口吃。

您的计算机上不太可能也运行 f.lux。但您可能正在经历类似的后台干预。您需要自己查找系统问题的根源。我写了一篇关于如何诊断跳帧的博客文章：诊断 DirectX 应用程序中的跳帧和卡顿 https://ewirch.github.io/2014/03/diagnose-frame-skips-and-stutter-in-directx.html。您还可以在那里找到诊断 f.lux 罪魁祸首的整个故事。

但即使您找到了跳帧的根源，我也怀疑您在启用 dwm 窗口合成时能否实现稳定的 60fps。原因是，您没有直接在屏幕上绘图。但相反，您绘制到 dwm 的共享表面。由于它是共享资源，因此其他人可以将其锁定任意时间，从而使您无法保持应用程序的帧速率稳定。如果您确实需要稳定的帧速率，请全屏显示或禁用窗口合成（在 Windows 7 上。Windows 8 不允许禁用窗口合成）：

#include <dwmapi.h>
...
HRESULT hr = DwmEnableComposition(DWM_EC_DISABLECOMPOSITION);
if (!SUCCEEDED(hr)) {
   // log message or react in a different way
}