Hi,
Has anyboday had the problem that when using the JoGL package, the gl.glCopyTexSubImage2D function is very slow?
When I used the function glCopyTexSubImage2D in my C++ program, it is reasonably fast…
Any idea or similar experiences?
Thanks.
Hi,
I encountered the same problem under Windows 2000 and a GeForce FX 5900 XT. My program updates every 40 ms a texture line per line (2048 pixels width, 1 pixel height). It is very slow, and hogs the CPU.
I have just changed the height parameter of the glCopyTexSubImage2D from 1 to 2; the update is still done line per line. This modification solves my problem. I think it is a bug in the NVidia driver, but it is just a feeling.
My texture is 128x128, and I specified it as a rectangular texture. Its performance is very similiar to yours, which takes a little bit more than 40ms to copy from the pbuffer to the texture.
Would you please tell me what are the formats of your texture and pbuffer? What’s the performance after you changed your texture to 2048x2?
Thank you very much. 
Hi moon,
I realize that I have made a mistake. It was very late when I posted my previous reply, that’s the reason why. My problem is related to the glTexSubImage2D function. I create a 2048 x 2048 texture, then every 40 ms I modify a line of the texture (2048 x 1) with a call to glTexSubImage2D, whose dimension parameters are then width = 2048 and height = 1.
With height = 1, the update is very slow, the CPU runs at 100 %. If I change only the height parameter to 2, everything works fine, the CPU is ridiculous. I don’t understand what is happening. I have the same problem under Windows and Linux, so it is unlikely to be a driver problem, as I said above. The format of the texture is GL_LUMINANCE.
Anyway, can you tell me if you are running under Windows or Linux ?
Hello,
just a quick thought, do you have the same color-depth and pixel-format for you pbuffer and the texture?
I had the same problem a while ago, and different pixel-formats really kill your performance.
Jan
Hi,
I am running the program under WinXP. We’ve turned to use render-to-texture instead of copy-to-texture and now it is much better… But I still don’t understand why using glCopyTexSubImage2D in jogl is so slow.
Yes, I did check the formats of the pbuffer and texture carefully and they do match each other… 