Sign in to follow this  

What is the fastest way to draw an image in OpenGL?

This topic is 2843 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

What is the fastest way to draw an image in OpenGL? Use DrawPixels or use textures? I just want to draw a background image and its size is not the power of 2. I have to redraw in every frame. Now I first just draw the image in an aux buffer and then use glCopyPixels to copy it into GL_BACK. But it only works on Mac but not on Windows, and it's not that fast... In addition, if I want to save part of the rendered image and reuse it, what is the fastest way?

Share this post


Link to post
Share on other sites
Disclaimer: I don't actually use Open GL at all at present, but I do have my own software 3D engine.

It shouldn't matter that your texture size isn't a power of two unless you wanted to tile it. Simply draw it into a texture that is a power of two in size and use a quad covering the whole screen, where the texture coordinates of the quad only go up to the actual height and width of your image.

Share this post


Link to post
Share on other sites
"Drawing" means if you have a pow2 texture, you can send a smaller subimage to the texture, and you don't care about the rest of the texture (it will be black, but I'm not sure, maybe undefined?).

You can specify the texture coordinates anyway you want:
You can have s<1.0, or t<1.0 coordinates, but I say: work it out with a pen and a piece of paper (it's so easy!). (I should include that in my signature.)

Share this post


Link to post
Share on other sites
I too would go for rendering the texture onto a pow2 quad as described above, then rendering a subsection of the quad to fill the screen. This should be PLENTY fast compared to some of the scary stuff we end up doing on a multiple-passes-per-pixel basis with shaders.

Share this post


Link to post
Share on other sites
Quote:
From OpenGL 2.0 specification
I.3 Non-Power-Of-Two Textures
The restriction of textures to power-of-two dimensions has been relaxed for all texture targets, so that non-power-of-two textures may be specified without generating errors. Non-power-of-two textures was promoted from the ARB_texture_non_power_of_two extension.


Unless you want to support very old hardware there is no power of two restriction. Non power of two textures also don't require any extensions since OpenGL 2.0, simply create a texture as big as the backbuffer.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kambiz
Quote:
From OpenGL 2.0 specification
I.3 Non-Power-Of-Two Textures
The restriction of textures to power-of-two dimensions has been relaxed for all texture targets, so that non-power-of-two textures may be specified without generating errors. Non-power-of-two textures was promoted from the ARB_texture_non_power_of_two extension.


Unless you want to support very old hardware there is no power of two restriction. Non power of two textures also don't require any extensions since OpenGL 2.0, simply create a texture as big as the backbuffer.

I'm making an educated guess here, but I suspect that a power of two sized texture would be marginally faster, considering the work required for indexing into the texture in each case. A non-power of two texture size requires an extra divide per pixel in a software renderer at least. Might not even be a measureable difference though I guess.

Share this post


Link to post
Share on other sites
Quote:
Original post by iMalc
A non-power of two texture size requires an extra divide per pixel in a software renderer at least. Might not even be a measureable difference though I guess.


Just take the inverse and it becomes a multiplication. So only one or two divs per texture.

Share this post


Link to post
Share on other sites
you could just compile a display list with a texture image on a quad in the negative z direction so its displayed further back,(dosn't have to be power of two with mipmapping) and call the display list every frame. this speeds it up a bit.

Share this post


Link to post
Share on other sites
Fastest way is a vertex array object representing your quad with VBOs attached for vertices, indices, tex coords and the image on a texture

Basically nothing other than VAOs/VBOs are supported in OpenGL 3.x+. If you get a 3.0+ header nothing else will compile. They made that choice for a reason [smile]

-me

Share this post


Link to post
Share on other sites

This topic is 2843 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this