something is "still" blocking my render loop

OpenGL Development JOGL Development
#1

hello, about a month ago, i had this problem:

http://www.java-gaming.org/forums/index.php?topic=14123.0

thanks to you guys, i could almost track it down that the FULL garbage collection was responsible for blocking the render loop.

now i have eliminated the FULL garbage collection but unfortunately i still get blockings in my renderthread, whenever i upload new textures to the VRAM.

it is basically this function:
Texture = TextureIO.newTexture( textureData );

if the player constantly walks around, it is called about 15 times per second and my textures are 128x128 RGB. that sums up to 720KB if i am not mistaken.
the framerate drops down to 4 fps, which is extremely noticeable.

is there no way to do the texture uploading in another thread than the animator?

my card is a GF 7200 but it happens with all other cards i have tried, too.

thanks!

#2

If you upload the same textures over and over again, you should know there is no reason to do that every frame.
You can simply upload all your textures at the start of your program (the init() of the GLEventListener is a good place), and later you only have to do texture.bind() right before you want to use the texture.

good luck :slight_smile:

#3

thanks.
all the textures are individual. and since i have such a huge number of textures, i cant load them all in the init() function, but i have to load and unload them at runtime.

#4

First, are you deleting those texture objects when they’re no longer needed? Second, are you aware of the differences between creating a new Texture object and simply updating the contents of one using glTexSubImage2D? The TextureIO APIs support creation of an OpenGL texture object and then repeated updating of it using Texture.updateSubImage(), and if you have a “texture pool” in your application you should probably populate it with texture objects of the appropriate size and then update those textures’ contents at run time. Note that when you update a texture’s contents you can not change its size; you need to delete and re-create the texture object in order to do that.

#5

thanks, Ken.

yes, i have tried both, so the number of texture objects remains constant.
i tried disposing and recreating the textures as well as updating them by calling updateSubImage(), but without any difference.
the same kind of blocking occurs.

the amount of texture data never changes. it’s always 128x128x3.

what exactly does this function do?
texture = TextureIO.newTexture( textureData);

i was looking at the jogl source, but all i found was
newTextureDataImpl
which i could not find anywhere else.

thank you!

#6

Look at TextureIO.java and Texture.java, in particular Texture.updateImage(). It creates an OpenGL texture object using glTexImage2D and updates its contents using glTexSubImage2D.

I don’t think you should see any rendering hiccups if you’re only updating some small number of textures of that size per frame. Have you double-checked and profiled your application to make 100% sure you know what’s going on with your texture handling?

#7

I agree with Ken that it seems strange that texture uploads of less than a meg are causing such a drop in frame rate. The only time I’ve been able to cause that myself was by combining compressed textures with the SGIS_generate_mipmap extension (which wasn’t really unexpected behaviour to be honest :slight_smile: ). What kind of output do you get from profiling your app?

#8

thank you both,

the thing that made me think of jogl, was that if i just comment out the line
texture = TextureIO.newTexture( textureData );
then the hiccups are gone. of course i dont have any texture changes at runtime anymore then. :-/

does the animator thread have a specific name? cause i cant find it in the netbeans profiler.

#9

Do you have any calls to Texture.dispose() in your application? You need to call this when you’re done with a particular OpenGL texture object, or else you’ll have a huge texture memory leak in your application.

#10

yes, i am doing Texture.dispose() and the memory footprint stays pretty constant as the player walks around in the world.

meanwhile, i am back to the theory that it is the blocking of the threads that is causing the hiccups, since the TextureData is a ressource that is on the one side generated by the thread that calculates the textures and on the other side it is read by the animator thread that wants to upload it to the graphics card. by doing texture = TextureIO.newTexture( textureData );

i think i have to investigate this further. does anyone know of programming techniques that avoid the blocking of the animator thread even though it has to access ressources that may currently be blocked by another thread.

thank you all so far!