🔒 Locked

Optimised dynamic textures

Started by superpig Mar 22, 2003 at 12:24 PM 5 replies 600+ views

Original Post

Mar 22, 2003 at 12:24 PM

Hey, I''m trying to write classes to render a movie using OpenGL and DirectShow. It''s working so far, except... Each frame, while the movie is playing, I call a set of gl functions to update the gl texture with the current frame data. I can''t guarantee that the video stream has power-of-two sizes, so I call gluScaleImage(); then, build the texture with glTexImage2D(); then, fix a couple of parameters with glTexParameter(). When I run the app, the framerate drops pretty badly. I''m absolutely sure it''s the glScaleImage()/glTexImage()/glTexParameter() set of calls, because when I cut them out (just use the same texture as the previous loop) the framerate goes right back up again. I would guess that it''s the glScaleImage() function which slows things down the most. Is there any way that I can optimise this, or do I just have to ensure that video files are powers-of-two in sizes? Thanks in advance. Superpig - saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.

falkone

Mar 22, 2003 at 12:33 PM

Process and store everything before you use it?

Null and Void

Mar 22, 2003 at 12:42 PM

One thing you can do is not scale the image if possible. Have the texture be the next power-of-two size up in both dimensions and use texture coordinates to select the correct portion when rendering.

Mayrel

Mar 22, 2003 at 3:10 PM

You could use glTexSubImage to update the texture. This will usually be faster than glTexImage - but note that you must use glTexImage the /first/ time you load the texture.

The other advantage of glTexSubImage is that the image you load into texture memory needn''t have power-of-two dimensions.

To take full advantage of this, you should load the first frame of your movie into a power-of-two buffer, and then use glTexSubImage to update the portion of the texture that contains the movie image for each frame.

When rendering the image, do as Null and Void suggests and mangle the texture coordinates so as to clip to the region of the texture that contains the image from the movie. That way, you can still scale the image to fit, but it''ll be done by your graphics hardware rather than GLU.

Best viewed with irony.

Hail Eris! All fnord hail Discordia!

James Trotter

Mar 22, 2003 at 3:30 PM

glTexSubImage() would be way, way, way faster, and you should definitely implement it!

superpig

Mar 22, 2003 at 3:36 PM

Ah, OK, I get it - I create a black, power-of-two surface when the movie is loaded, and then render each movie frame into the top-left corner...

That means I''ll have to replace the memcpy() call I made to copy the frame into my temporary buffer with something more elaborate... but given that it was originally handling multiple texture formats and what have you, it shouldn''t cost too much.

Thanks very much, folks.

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.

superpig

Mar 23, 2003 at 3:31 AM

It worked even better than I''d thought - glTexSubImage lets you update just a rectangle on the texture (rather than the whole mipmap level) so my frame extraction operation stayed as a memcpy and didn''t have to use an extra buffer. Superb.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.