I want to display a “backdrop” image on a 1024x768 resolution. This image will change frequently (video stream, more or less) but I am using a “custom” image file format. I was curious which of these 2 mehtods would be the best/fastest.
Break the incomming backdrop image up into chunks (like 12 256x256, or 3 1024x256, etc) images, and texture them onto quads setup accross the screen backdrop. To do this I would need to load x number of textures from my texture data, them draw x number of quads on the screen, then texture them, etc.
Benifits: Easy to allow opengl to manipulate the size of the image if the resolution is changed.
Draw backs: Will use a fair amount of texture space, and will cause alot of texture memory to be swapped in and out each frame.
OR
Simply load my “array” of color values directly into the color buffer using glDrawPixels.
Benifits: Not having to use any texture memory to hold my backdrop each frame, no swaping the textures in and out of memory, or creating new textures each frame.
Drawbacks: Very difficult to “reshape” the window from 1024x768. Possibly slower?
You can use glTexSubImage2D to avoid recreating textures each frame. This will probably be your fastest option. glDrawPixels probably won’t be as fast as loading and drawing a texture and offers no advantages beyond memory useage which is probably a secondary concern. Having a texture allows for filtering, warping and otehr effects.
DO NOT use multiple textures with multiple loads, that could significantly reduce performance.
Use a 1024x1024 texture and have an unused pad in the portion your video does not fill.
Ok, I thought of another method, what do you think of this. For each pixel draw a quad, and then simply set its color to the corresponding color. Once again this wouldnt be highly resizable, but texture calls and texture memory swaps would be almost illiminated, but it does require drawing 1024x768 quads. But on the same token, they are small, 1 color, and no lighting/anything else done to them.
Originally posted by MateeC: It would be faster with GL_POINTS than with GL_QUADS, but as far as i know 1 big textured quad is faster then a lot of tiny ones.
Yes, certainly that would be faster since drawing 1 quad needs 4 vertices while drawing a point simply requires a single vertex. :]
Also I agree that going for textures would be the best solution (in my opinion, of course). It would also make image’s management a lot easier.
It’s probably an horrendous suggestion. You’d have to send xyz and rgb per point at least and the T&L engine would have to transform it to the screen. I assume you’d use VBO etc to do this and use vertex arrays of some sort, this might give you a contiguous color block to deal with in host memory but you’d need to specify colors as an appropriate type and hope it could be optimally sent to hadrware with the verts positions.
You could try it, but my advice is just create the darned texture and stop asking silly questions .
.