windows - 当线程在 SwapBuffers() 中被阻塞时 GetMessage()

Question

Vsync 阻塞 SwapBuffers()，这正是我想要的。我的问题是，由于输入消息转到拥有窗口的同一个线程，因此在 SwapBuffers() 被阻止时进入的任何消息都不会立即处理，但只有在 vsync 触发缓冲区交换并且 SwapBuffers() 返回之后.所以我让我的所有计算线程都处于空闲状态，而不是使用最近的输入处理场景以在下一帧中渲染。我特别关心具有非常低的延迟。我需要一些方法来从其他线程访问所有待处理的输入消息到窗口。

Windows API 提供了一种使用 MsgWaitForMultipleObjects() 来等待 Windows 事件或输入消息的方法，但没有类似的方法来等待缓冲区交换和其他东西。这是非常不幸的。

我考虑在另一个线程中调用 SwapBuffers()，但这需要在窗口的线程中调用 glFinish()，然后再向 SwapBuffers() 发出另一个线程，并且 glFinish() 仍然是一个阻塞调用，所以它不是一个好的解决方案。

我考虑过 Hook ，但这看起来也像死路一条。与 WH_GETMESSAGE Hook 将不会异步调用 GetMsgProc()，但是当窗口的线程调用 GetMessage()/PeekMessage() 时，它没有任何帮助。由于需要使用特定的窗口句柄调用 RegisterTouchWindow() 来处理 WM_TOUCH，因此安装全局钩子(Hook)对我也没有帮助——而且我的输入是触摸。而且，对于鼠标和键盘，您可以安装低级钩子(Hook)，在消息发布到线程队列时捕获消息，而不是在线程调用 GetMessage()/PeekMessage() 时，似乎没有类似的触摸选项.

我还查看了 wglDelayBeforeSwapNV()，但我看不出是什么阻止了操作系统有时在调用该函数之后但在 SwapBuffers() 之前抢占线程，从而导致错过下一个 vsync 信号。

那么有什么好的解决方法呢？我可以制作第二个不可见的窗口，它会以某种方式始终处于事件状态，从而获取所有输入消息，而可见的窗口正在显示渲染？根据另一个讨论，仅消息窗口(带有 HWND_MESSAGE 的 CreateWindow)与 WM_TOUCH 不兼容。是否有一些 SwapBuffers() 在内部等待我可以访问并提供给 MsgWaitForMultipleObjects() 的未记录事件？我的目标是一个固定平台(Windows 8.1 64 位)，所以我可以使用未记录的功能，如果它存在的话。但是，我确实想避免编写自己的触摸屏驱动程序。

Answer 1

出于好奇，为什么不在另一个线程中实现整个绘图逻辑呢？您遇到的问题似乎是消息泵是由绘制的同一线程驱动的。由于 Windows 不允许您从与创建窗口的线程不同的线程驱动消息泵，因此最简单的解决方案是将所有 GL 内容推送到不同的线程中。
SwapBuffers (...)也不一定要去堵。根据 VSYNC 的要求，实现只需要在 时阻止将修改后缓冲区的下一个命令。全部 后备缓冲区正在等待交换。三重缓冲通过引入第二个后缓冲来稍微改变一下。

三重缓冲的一种可能实现将在交换时丢弃最旧的后备缓冲区，因此 SwapBuffers (...)永远不会导致阻塞(这实际上是现代版本的 Windows 在启用 DWM 的 窗口化 模式下的工作方式)。其他实现最终将同时呈现两个后缓冲区，这会减少(但不会消除)阻塞，但也会导致延迟帧的显示。

不幸的是，WGL 不允许您请求交换链中的后缓冲区数量(超出 0 单缓冲或 1 双缓冲)；在 Windows 上获得三重缓冲的唯一方法是使用驱动程序设置。最低的消息延迟将来自于在不同的线程中驱动 GL，但三重缓冲可以提供一点帮助，同时无需您付出任何努力。