Copying pixel data to texture faster than glTexSubImage2D?

Hello,

What I am trying to do is render the contents of a Java bufferedimage to the screen overtop of an OpenGL canvas.  The BufferedImage has its pixel data completely changed each frame.

To do this, I copy the contents of the buffered image to a texture using

gl.glBindTexture(GL.GL_TEXTURE_2D, textureId);
gl.glTexSubImage2D(GL.GL_TEXTURE_2D, 0, 0, 0, textureSize, textureSize, GL.GL_BGRA, GL.GL_UNSIGNED_BYTE, IntBuffer.wrap(pRawData));

then this quad is drawn in screen space. It works, but takes about 7ms on my PC with a 2048x2048 texture.  The performance bottleneck is the glTexSubImage2D call.

Any suggestions for improving this speed?

Thanks,

Jesse

Hi

Rather use direct NIO buffers. You can directly manipulate the NIO buffer created by the data model of the buffered image, look at the source code of GLJPanel and AWTTextureIO, Sven can probably show you exactly where he does something similar. There are probably other ways to do that, by using a FBO for example.

Thanks for the response. Just to clarify - I have the data model of the buffered image, manipulating it is not the issue.  The issue is copying this data to the screen.  

Looking at GLJPanel it looks like it might use pixel buffers, but I have heard that they are deprecated.  It does sound like the right thing though.  I could setup an FBO but not sure that would really be faster - manually drawing 2048x2048 pixels into an FBO through a pixel shader sounds slow to me!

If Sven is available to give some insight that would be great. Thanks!

Jesse

Actually, the "pixel buffer" is not deprecated, it uses a software pixmap or a pbuffer depending on the platform. I advise you to look at the internal class OffscreenBackend within GLJPanel.

Moreover, keep in mind that FBOs and pbuffers are very slow on some hardwares (particularly Intel chips). Rather use vectorized data and optimize your rendering if it isn't faster enough. If you use vectorized data with a tool or a library that converts them into images, you won't get any speedup.

Well after looking through these classes the conclusion I've come to is that glTexSubImage2D is the fastest way to do this.  I guess the problem is that copying 4mb of pixels from RAM to VRAM is slow.

Looks like pbuffers or FBO's are useful if you are rendering to an offscreen texture, but offer no speed gain (actually, slower) if the source pixel data is in RAM (like the case I have).

Using a PBO to do the transfer is useful if you are asynchronously copying from RAM->VRAM, but that's not the case for me as everything is waiting on this transfer to be finished.

If this sounds wrong please let me know because I've given up!

Jesse

It depends on what you mean by "slow" but I agree with your conclusion. As long as you are forced to transfer those pixels from the RAM, it will be a bit slow especially on big images like yours (2048 * 2048). Buffer objects can offer a speed gain but it greatly depends on your hardware.

I had to solve a similar problem several months ago and I concluded that I had to switch to vectorized data to get a huge speedup but it isn't a general solution. If your data can't be easily vectorized, it isn't worth a try.