什么可能导致 OpenGL 在“开始调试”与“开始而不调试”选项下的行为不同？答案

【问题标题】：What might cause OpenGL to behave differently under the "Start Debugging" versus "Start without debugging" options?什么可能导致 OpenGL 在“开始调试”与“开始而不调试”选项下的行为不同？
【发布时间】：2010-12-20 10:07:45
【问题描述】：

我用 C++ 编写了一个 3D 立体 OpenGL 程序。我在 timeBeginPeriod(1) 之后使用 timeGetTime 跟踪显示中的位置对象。当我使用“开始调试”运行程序时，我的对象在显示器上平滑移动（它们应该如此）。当我使用“开始而不调试”运行程序时，对象偶尔会冻结几次屏幕刷新，然后跳转到新位置。关于可能导致此问题的原因以及如何解决此问题的任何想法？

编辑：如果我单击鼠标按钮，当我运行“不调试就开始”时，似乎可以在短暂的延迟后解决抖动问题。我的应用程序是一个控制台应用程序（我在程序第一次启动时接受了一些参数）。这两个选项之间的窗口焦点可能有所不同吗？当我从控制台窗口完成输入后，是否有一种明确的方法可以将焦点强制到 OpenGL 窗口（通过 glutFullScreen(); 全屏显示）？

谢谢。

【问题讨论】：

您的发布版本表现如何，您的整体 CPU 使用情况如何？
由于我几乎完全在开发环境中工作，而且我渲染的简单显示不应该成为 CPU 使用率的问题，因此我从未构建过发布版本。我最近这样做的尝试被我一直在使用的一个屏幕捕获库阻止了，该库拒绝正确链接。运行进程的核心的 CPU 利用率很高，但很少固定。

标签： c++ windows opengl timer stereo-3d

【解决方案1】：

timeGetTime API 的精度只有 10 毫秒左右。如果您测量的间隔小于 50 毫秒左右，您可能只是看到了系统计时器中预期变化的影响。我不知道为什么调试器会对此产生影响，但是系统的整个工作都是一个黑匣子。您可以使用QueryPerformanceCounter 获得更高分辨率的计时，这可能会有所帮助。

【讨论】：

谢谢，我去看看。我曾认为 timeBeginPeriod(1) 准确地将分辨率设置为 1ms。如果分辨率是@10ms，那肯定会给我的代码带来一些问题。
@drknexus timeGetTime 和 timeBeginPeriod 的文档暗示它是 1ms，但它似乎高度依赖于可用的硬件。我想“现代”硬件可能已经解决了这个问题，我玩它已经有几年了。这是我记得 10ms 值的地方，但它也是几年前的：support.microsoft.com/kb/172338

【解决方案2】：

导致任何程序在被调试和未被调试时表现不同的最常见的事情是使用未初始化的变量，尤其是读取未初始化的内存。检查你没有这样做。

更具体的 OpenGL - 您可能在刷新命令时遇到一些问题。尝试在绘制每一帧后插入glFinish()。
以某种方式真正确保发生冻结时确实存在正在渲染的帧而不是整个应用程序被冻结也可能会有所帮助。如果您更有可能在逻辑中有一些错误，因为 OpenGL 似乎可以完成它的工作。

【讨论】：

感谢您的建议。关于如何确定在明显冻结期间是否仍在渲染帧的任何建议？我之前曾尝试过检查，但发现由于写入文件而导致的速度变慢掩盖了正在发生的事情。由于这是一个 120Hz 的立体声显示，我有大约 8.33 毫秒的时间来完成整个显示循环。
通常调试版本会以完全相同的方式初始化内存，无论是否通过调试器运行。在 Windows 上，您仍将使用调试运行时库。迁移到发布版本时会产生很大的不同。