glDrawPixels(256, 192, GL_BGRA_EXT, GL_UNSIGNED_BYTE, surfs[index].psurfacemem);
glDrawPixels slow?!
Author
Hi everyone!
I am using glDrawPixels to draw a 2D surface to the screen. But I am getting lacklustre performance. I didnt want to go through the 3D pipeline but if I cannot get the performance I want from it, I will utilize a textured quad (btw, the image has non-power of 2 dimensions, I will figure a way, I need it to be stretched anyway). I am using it in the following fashion:
Heis man.
As I have read somewhere (openGL red book? maybe!), the functions that manipulate pixels (like drawing and copying) are VERY slow.
The possibility is really a screen aligned quad with a power of two texture.
About the other question, I didn't undertand it well, but, you can scale, translate, rotate, skew and dow whatever you want with the qaud since it is 2 textures and will use the hardware to rasterize them.
As I have read somewhere (openGL red book? maybe!), the functions that manipulate pixels (like drawing and copying) are VERY slow.
The possibility is really a screen aligned quad with a power of two texture.
About the other question, I didn't undertand it well, but, you can scale, translate, rotate, skew and dow whatever you want with the qaud since it is 2 textures and will use the hardware to rasterize them.
try compiling the glDrawPixels command into a dsiplay list . This will increase performance
if the images are not to be changed frequently. If u do want to change the image u will have to rebuild the display list
if the images are not to be changed frequently. If u do want to change the image u will have to rebuild the display list
Been looking at this myself recently, although I found performance pretty good for just applying to the colourbuffers (drawing to the depth buffer was horrendously slow < 0.1 fps).
Whilst reading up on it I came across the fact that it still goes thorugh the basic 3d pipeline, meaning that it does not pixel fragrement ops on it. I can't find the source now, but i'm positive it was suggest to disable states like the depthbuffer, alphatesting etc before calling glDrawpixels to improve performance.
Can't say for sure if these actually have an impact, only just started looking into it, but from the msdn opengl docs I found this
'These pixel fragments are then treated just like the fragments generated by rasterizing points, lines, or polygons. The glDrawPixels function applies texture mapping, fog, and all the fragment operations before writing the fragments to the framebuffer.'
As to using a screen aligned quad, you could look into the Non-Power of 2 texture extension.
[Edited by - noisecrime on August 31, 2005 9:36:11 AM]
Whilst reading up on it I came across the fact that it still goes thorugh the basic 3d pipeline, meaning that it does not pixel fragrement ops on it. I can't find the source now, but i'm positive it was suggest to disable states like the depthbuffer, alphatesting etc before calling glDrawpixels to improve performance.
Can't say for sure if these actually have an impact, only just started looking into it, but from the msdn opengl docs I found this
'These pixel fragments are then treated just like the fragments generated by rasterizing points, lines, or polygons. The glDrawPixels function applies texture mapping, fog, and all the fragment operations before writing the fragments to the framebuffer.'
As to using a screen aligned quad, you could look into the Non-Power of 2 texture extension.
[Edited by - noisecrime on August 31, 2005 9:36:11 AM]
from http://www.opengl.org/resources/faq/technical/performance.htm:
"Why are glDrawPixels() and glReadPixels() so slow?
[...]
First, all glPixelTransfer() state should be set to their default values. Also, glPixelStore() should be set to its default value, with the exception of GL_PACK_ALIGNMENT and GL_UNPACK_ALIGNMENT (whichever is relevant), which should be set to 8. Your data pointer will need to be correspondingly double- word aligned.
Second, examine the parameters to glDrawPixels() or glReadPixels(). Do they correspond to the framebuffer layout? Think about how the framebuffer is configured for your application. For example, if you know you're rendering into a 24-bit framebuffer with eight bits of destination alpha, your type parameter should be GL_RGBA, and your format parameter should be GL_UNSIGNED_BYTE. If your type and format parameters don't correspond to the framebuffer configuration, it's likely you'll suffer a performance hit due to the per pixel processing that's required to translate your data between your parameter specification and the framebuffer format.
Finally, make sure you don't have unrealistic expectations. Know your system bus and memory bandwidth limitations."
I suggest you try GL_RGBA instead of GL_BGRA_EXT to see if this is the cause of the sluggish performance.
"Why are glDrawPixels() and glReadPixels() so slow?
[...]
First, all glPixelTransfer() state should be set to their default values. Also, glPixelStore() should be set to its default value, with the exception of GL_PACK_ALIGNMENT and GL_UNPACK_ALIGNMENT (whichever is relevant), which should be set to 8. Your data pointer will need to be correspondingly double- word aligned.
Second, examine the parameters to glDrawPixels() or glReadPixels(). Do they correspond to the framebuffer layout? Think about how the framebuffer is configured for your application. For example, if you know you're rendering into a 24-bit framebuffer with eight bits of destination alpha, your type parameter should be GL_RGBA, and your format parameter should be GL_UNSIGNED_BYTE. If your type and format parameters don't correspond to the framebuffer configuration, it's likely you'll suffer a performance hit due to the per pixel processing that's required to translate your data between your parameter specification and the framebuffer format.
Finally, make sure you don't have unrealistic expectations. Know your system bus and memory bandwidth limitations."
I suggest you try GL_RGBA instead of GL_BGRA_EXT to see if this is the cause of the sluggish performance.
glDrawPixels will always be slow, no matter what format you're using. The reason is that it requires the image data to be transferred from RAM(the *pixels parameter) to the video card. On the other hand, using a textured quad means that the texture is always loaded in the VRAM, and so it's much faster. You don't need to learn everything about the 3D pipeline if you want just 2D capabilites, you just set the correct orthographic projection and deal with 2D coordinates only.
no, as its not an execution time problem its a data readback and pipeline issue.
Display lists arent a magic fix for everything in OpenGL.
Display lists arent a magic fix for everything in OpenGL.
Does anyone here knows, how could I efficiently save/restore power-of-two depth/stencil screen rectangle?
Don't ask me, why do I need this!!! ))))
The problem is how I can efficiently save/restore depth and stencil info. I tried to accomplish it with a help of ReadPixels/DrawPixels, taking into account all the issues, found in specification and that, what you were talking about, but perfomance is still very poor.
Thnx in advance!
--- edit
Oops! I found, what I need! WGL_ARB_buffer_region - very helpful extension, if you have similar problem. It is much faster, than ReadPixels/DrawPixels, because of lack in VideoCard/RAM transfers, fortunately, no transfers at all.
[Edited by - Jackis on September 1, 2005 11:53:21 AM]
Don't ask me, why do I need this!!! ))))
The problem is how I can efficiently save/restore depth and stencil info. I tried to accomplish it with a help of ReadPixels/DrawPixels, taking into account all the issues, found in specification and that, what you were talking about, but perfomance is still very poor.
Thnx in advance!
--- edit
Oops! I found, what I need! WGL_ARB_buffer_region - very helpful extension, if you have similar problem. It is much faster, than ReadPixels/DrawPixels, because of lack in VideoCard/RAM transfers, fortunately, no transfers at all.
[Edited by - Jackis on September 1, 2005 11:53:21 AM]
Quote:Original post by Jackis
Oops! I found, what I need! WGL_ARB_buffer_region - very helpful extension, if you have similar problem. It is much faster, than ReadPixels/DrawPixels, because of lack in VideoCard/RAM transfers, fortunately, no transfers at all.
Apart from the fact that its not support on a large range of ATI cards.
<A HREF="http://www.delphi3d.net/hardware/extsupport.php?extension=WGL_ARB_buffer_region>Hardware support
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
