OpenGL 与 GLUT——malloc 错误
我想从已在 OpenGL 中渲染的 GLUT 窗口中屏幕抓取图像。在显示回调的一侧，我插入了以下代码：
display() {
drawTriangle(); //Renders the image
if(shouldDisplay) {
shouldDisplay=0;
bytes = width*height*3; //Color space is RGB
buffer = (GLubyte *)malloc(bytes); //buffer is global var for now
glFinish();
glReadPixels(0, 0, width, height, GL_RGB, GL_UNSIGNED_BYTE, buffer);
}
glutSwapBuffers();
}
此代码运行后，malloc 开始失败。它失败并出现 ENOMEM，错误 12。我对操作系统或 GLUT 的了解不够，无法理解为什么会发生这种情况。我只想在 3 GB 的机器上分配 17K。我使用的是 Windows XP 和 Visual Studio C++ 2010 Express。任何帮助或建议表示赞赏。
I want to screen scrape the image from a GLUT window that has been rendered in OpenGL. In side of the display callback I inserted this code:
display() {
drawTriangle(); //Renders the image
if(shouldDisplay) {
shouldDisplay=0;
bytes = width*height*3; //Color space is RGB
buffer = (GLubyte *)malloc(bytes); //buffer is global var for now
glFinish();
glReadPixels(0, 0, width, height, GL_RGB, GL_UNSIGNED_BYTE, buffer);
}
glutSwapBuffers();
}
After this code runs, malloc starts failing. It fails with ENOMEM, error 12. I don't know enough about operating systems or GLUT to understand why this is happening. I'm only trying to allocate 17K on a machine with 3 GB. I'm using Windows XP and Visual Studio C++ 2010 Express. Any help or suggestions is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
该代码最后错过了一个
free(buffer)，因此每次重绘都会消耗越来越多的内存，直到进程耗尽内存和/或地址空间（后者仅在 32 位系统上） ，因为在合理的时间内通过少量分配很难耗尽 64 位地址空间）。That code misses a
free(buffer)at the end, so with each redraw more and more memory is consumed until the process runs out of memory and/or address space (the later only on a 32 bit system, since 64 bits of address space are hardly to exhaust with small allocations in a reasonable time).在调用 glReadPixels 之前尝试
glPixelStorei(GL_PACK_ALIGNMENT, 1);。Try
glPixelStorei(GL_PACK_ALIGNMENT, 1);before calling glReadPixels.让我重新表述一下这个半吊子的答案。我认为堆正在被废弃，可能是由于缺少 free() 和连续分配，可能是由于 glReadPixels 覆盖了目标缓冲区。
大多数帧缓冲区至少是 32 位/双字对齐的，这表明，正如此处的注释所述，w*h*4 字节可能只是工作，因为它与内部表示匹配。
将对齐设置为 1 字节（就像另一个答案所说的那样）对我来说也很好。
Let me rephrase this half-cocked answer. I think the heap is being trashed, perhaps by a missing free() and consecutive allocations perhaps by glReadPixels overwriting your target buffer.
Most framebuffers are at least 32-bit/dword aligned which suggests that, as the comment here says, w*h*4 bytes might just work as it matches the internal representation.
Setting the alignment to 1 byte (like another answer says) seems fine too to me.