Jump to content
  • Advertisement
Sign in to follow this  
x86asm

glDrawPixels slow?!

This topic is 4824 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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:
glDrawPixels(256, 192, GL_BGRA_EXT, GL_UNSIGNED_BYTE, surfs[index].psurfacemem);
I used both a Radeon 9550 (w/ 9600 BIOS) and a SuperSavage 16MB on my T23 and the performance was bad on both of them (more so on the SuperSavage lol but I kinda expected that haha). Both of them looked as if they were scaling and drawing the image in software rather than using the hardware (a big indicator was the lack of filtering). Could this be because I am using the GL_BGRA_EXT ? The way I am generating the image doesnt allow me to use one of the non-extensions modes. If someone can offer some aid on how to set it up my pixel format is a DWORD in the following format : 0x00RRGGBB (appears as bytes like 0xBB 0xGG 0xRR 0x00). Also if I am forced to go the textured quad way how would I be able to get the image onto the screen properly without doing some scaling in software (which will definitely kill performance ) Thanks a bunch in advance :D

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!