c++ - 多线程 OpenGL/WinAPI 应用程序

Question

注意:请在发帖前通读全文，您会明白为什么。

所以我有一个 OpenGL/WinAPI 应用程序。我正在做你所期望的，通过循环处理消息，然后渲染帧，处理消息，渲染帧......

问题是，当我调整窗口大小或移动窗口时，屏幕会卡住，而且看起来很难看。我从以前的 OpenGL 过期中知道，限制帧之间要处理的消息数量(按数量或时间)可以解决问题。每当移动/调整窗口大小时，Windows 似乎都会阻止我的应用程序。从实验中，我确实知道将 Windows 消息处理放入另一个线程并忘记它工作得很好，并且也有助于计时。

我的问题是:是否有更好、破坏性更小或非线程化的方式来执行此操作？我正在做的事情有什么缺点吗(除了多线程戏剧)。我很想知道多线程是否可以避免。

Answer 1

当用户点击窗口的非客户区域来移动窗口或调整窗口大小时，DefwindowProc 进入模态循环，因此您的游戏循环不再执行 - 直到用户取消或完成模态操作。

有一些窗口消息可用于检测模态操作的开始和结束:WM_ENTERSIZEMOVE例如。

问题的症结在于，如果您的 OpenGL 窗口不是全屏，或者它显示消息框，那么您就不能依靠简单的游戏循环来继续渲染游戏 - 您需要切换到基于计时器的渲染器。

SetTimer可以创建一个计时器，即使在模态操作正在进行时也将发送 WM_TIMER 消息。

附言。关于线程的注意事项:OpenGL 上下文不是线程安全的，如果跨线程共享上下文，则访问必须序列化(由用户代码手动)。即使使用多个上下文，对实际设备的访问也会被序列化，因此多线程基于 OpenGL 的渲染器不会获得性能优势 - 除非(具有讽刺意味的是)你做了很多 CPU 密集型工作(然后像 OpenMP并行化循环比尝试设计更高级别的多线程渲染作业调度程序更有帮助)。基本上:坚持使用带有 OpenGL 的单线程渲染器 - 它将比几乎任何线程尝试都表现得更好，并且更容易预测。

PPS。对于窗口 OpenGL 应用程序，最好放弃传统的游戏循环方法来渲染每一帧，并依赖 RedrawWindow将 WM_PAINT 消息发送到窗口:在 BeginPaint/EndPaint block 内绘画意味着您的应用程序呈现行为更可预测，并且 DesktopWindowManager 进程可以处理其应用程序的工作毛玻璃效果，并尝试更有效地实现桌面到显示器的垂直同步更新。