在屏幕上绘制二维颜色三元组的最快方法是什么?
目标语言是C/C++,程序只需在Linux上运行,但显然首选独立于平台的解决方案。 我运行Xorg,XVideo和OpenGL都可用。
在配备英特尔显卡的英特尔酷睿 2 双核处理器上,我在 1024x768 上的预期帧速率是多少? (仅绘图计数,考虑 RAM 中准备就绪的阵列;不需要精确的预测)
The target language is C/C++ and the program has only to work on Linux, but platform independent solutions are preferred obviously. I run Xorg, XVideo and OpenGL are available.
How many FPS can I expect on 1024x768 on an Intel Core 2 Duo with Intel graphics? (ONLY drawing counts, consider the arrays to be ready in RAM; no precise prognosis needed)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
绘制颜色三元组的二维数组的最快方法:
GL_LUMINANCE
存储 - 速度更快!)glTexImage2D
将数组上传到纹理GL_TEXTURE_MIN_FILTER
纹理参数设置为GL_NEAREST
此方法比
glDrawPixels
稍快(由于某种原因往往实现得很糟糕),并且比使用平台的本机位块传输快很多。此外,当您的像素图未更改时,它还允许您重复执行步骤 4 而无需执行步骤 2,这当然要快得多。
仅提供慢速本机 blitting 的库包括:
至于您可以预期的 FPS,在具有 Intel 显卡的 Intel Core 2 Duo 上绘制 1024x768 纹理:如果纹理每帧都发生变化,则约为 60FPS;如果没有,则 >100FPS。
但你自己做一下看看吧;)
The fastest way to draw a 2D array of color triplets:
GL_LUMINANCE
storage when you don't need hue - much faster!)glTexImage2D
GL_TEXTURE_MIN_FILTER
texture parameter is set toGL_NEAREST
This method is slightly faster than
glDrawPixels
(which for some reason tends to be badly implemented) and a lot faster than using the platform's native blitting.Also, it gives you the option to repeatedly do step 4 without step 2 when your pixmap hasn't changed, which of course is much faster.
Libraries that provide only slow native blitting include:
As to the FPS you can expect, drawing a 1024x768 texture on an Intel Core 2 Duo with Intel graphics: about 60FPS if the texture changes every frame and >100FPS if it doesn't.
But just do it yourself and see ;)
我不久前使用 C 和 OpenGL 完成了此操作,通过创建全屏大小的四边形,然后使用纹理映射将位图传输到四边形的表面,获得了非常好的性能。
下面是一些示例代码,希望您能使用。
I did this a while back using C and OpenGL, and got very good performance by creating a full screen sized quad, and then use texture mapping to transfer the bitmap onto the face of the quad.
Here's some example code, hope you can make use of it.
如果您尝试将像素转储到屏幕,您可能需要使用 sdl
“表面”设施。 为了获得最佳性能,请尝试将输入数据安排为与输出表面类似的布局。 如果可能,请避免一次在表面上设置一个像素。
SDL 本身并不是一个硬件接口,而是一个可移植层,可以在许多其他显示层(包括 DirectX、OpenGL、DirectFB 和 xlib)之上很好地工作,因此您可以获得非常好的可移植性,而且它是一个非常薄的层基于这些技术,因此您只需支付很少的性能开销。
If you're trying to dump pixels to screen, you'll probably want to make use of sdl's
'surface' facuility. For the greatest performance, try to arrange for the input data to be in a similar layout to the output surface. If possible, steer clear of setting pixels in the surface one at a time.
SDL is not a hardware interface in its own right, but rather a portability layer that works well on top of many other display layers, including DirectX, OpenGL, DirectFB, and xlib, so you get very good portability, and its a very thin layer on top of those technologies, so you pay very little performance overhead on top of those.
除了 SDL 之外的其他选项(如上所述)
我的建议
Other options apart from SDL (as mentioned)
My suggestion
“我可以期望多少帧速率”这个问题无法得到认真的回答。 即使你说出进行处理器布局的人的祖父的名字也不会。 这取决于太多的变量。
这可能会永远持续下去,答案绝对取决于您的算法。 如果您坚持使用 opengl 方法,您还可以尝试不同的扩展(http://例如,我想到了www.opengl.org/registry/specs/NV/pixel_data_range.txt),看看它是否更适合您的需求; 尽管已经提到的 glTexSubImage() 方法相当快。
the "how many fps can i expect" question can not be answered seriously. not even if you name the grandpa of the guy who did the processor layouting. it depends on tooooo many variables.
this could go on for ever, the answer depends absolutly on your algorithm. if you stick to the opengl approach you could also try different extensions (http://www.opengl.org/registry/specs/NV/pixel_data_range.txt comes to mind for example), to see if it fits your needs better; although the already mentioned glTexSubImage() method is quite fast.