Winapi 在不使用vsync的情况下与监视器刷新同步

当vsync不是选项时，与监视器刷新同步的首选方式是什么？我们启用了vsync，但是，一些用户在驱动程序设置中禁用了它，这些设置覆盖了应用程序的首选项。我们需要可靠的可预测帧长度，以正确模拟世界、进行一些视觉效果和同步音频（更准确地说，我们需要估计帧在屏幕上的时间和长度）

不管用户在驱动程序中设置了什么，有没有办法强制驱动程序启用vsync？或者询问Windows何时将发生监视器重新刷新？当我们的帧边界与vblank紧密对齐时，我们会遇到手动睡眠的问题。它会导致偶尔的漏帧，以及最多1帧额外的输入延迟

---

我们主要使用OpenGL，但Direct3D建议也很受欢迎。

您不应该基于vsync和帧表示的精确计时来构建应用程序的计时。现在的游戏没有这样做，而且已经有相当一段时间没有这样做了。这使得他们即使开始掉帧也能保持一致的速度；因为他们的计时、物理计算、人工智能等不是基于帧的显示时间，而是基于实际计时

游戏帧定时通常足够小（小于50ms），人类无法检测到任何音频/视频同步问题。因此，如果你想显示一个应该有声音在旁边播放的图像，只要声音在图像30毫秒左右的范围内开始，你就可以了

哦，不用麻烦切换到Vulkan/D3D12来解决这个问题。他们没有。特别是Vulkan将演示与其他任务分离，因此基本上不可能知道图像开始出现在屏幕上的确切时间。你给了Vulkan一个图像，它展示了它。。。在下一个最合适的时刻。你可以在一定程度上控制那一刻是如何被选择的，但即使是那些选择也会受到你无法控制的因素的限制

---

设计您的程序以避免使用僵硬的vsync。改用内部计时。

这听起来像是在倒计时。你不想依赖外部资源来提供一个稳定的时钟，以便将现实与你的内部状态相匹配。相反，以基于当前时间建立真实感（包括同步资源的渲染帧）的方式编写系统。此系统不受用户选择进入或退出vsync的影响。@IInspectable如果不知道音频何时会出现在屏幕上并正确计算时间，则无法正确执行运动模糊或同步音频等效果。我并不是说我想依靠其他来源来同步，我只是想知道我的图像何时可能会出现在屏幕上。这不是你可以避免的。如果你想知道你的图像将出现在屏幕上的大致时间，就推断过去，不管你希望你的推断算法多么复杂。我不认为vsync会使这项工作变得更容易。这只是一种量化时间的方法。不使用vsync，您也可以量化计时。显然，您需要实现与帧速率无关的游戏循环（也就是说，无论演示文稿的FPS如何，都要使应用程序以相同的速率运行），但是，在不使用vsync的情况下，正确地确定演示文稿的目标可能很棘手。我不确定与强制禁用vsync的用户进行斗争是否有意义。“大多数人都不知道你的音频在这么短的时间内是否关闭了。”呃，不。一般训练有素的音乐家都能感觉到6-8毫秒左右的情况。32毫秒处于“糟糕”的范围内。使用内部计时如何解决帧丢失问题？如果我测量最后一帧的时间是30毫秒而不是16毫秒，因为它太慢了，我现在不想用这个时间来模拟，因为这个帧不太可能再慢了，所以它只会是一个显示16毫秒的帧，但会让世界前进30毫秒。我可以在一个单独的线程上进行所有模拟，我做了很多模拟，但是，实体位置和动画的外推也很复杂，因为显示时间和实时性不匹配。@Kalinovic：它通过不关心帧丢失来解决帧丢失问题。模拟应始终以特定的时间运行：15fps、30fps、60fps等等。在模拟帧之间显示多少图片无关紧要。当您决定渲染时，可以在模拟的两个帧之间进行插值，插值时间基于自上次渲染以来的时间长度。或者更具体地说，自上次开始渲染以来经过了多少时间。我知道这样做会使模拟时间等于所有帧的经过时间，但我不确定这是否真的是可取的。。。这似乎引入了另一个“额外模拟”尖峰来纠正之前的滞后尖峰。@kal：关键是你的代码根本不应该关心尖峰。它应该只渲染，给定当前的挂钟时间（或增量，基于任意选择的原点）。如果你删除了一个帧，它不会影响未来的帧。这个答案相当误导。使用帧率无关的游戏循环并不意味着应用程序不再需要关心帧显示的精确计时。如今的游戏不仅倾向于以即将到来的展示时间为目标，而不是当前（或游戏本地）时间，而且还采用先进的前向预测手段，试图减少延迟。而且帧定时非常严格，特别是在VR中，如果不能在8/11ms窗口内显示帧，将导致玩家严重晕车。