TextRenderer resource leak

Merry christmas to all of you.

Well, I currently on the hunt after ogl resource leaks in my application. OpenGL profiler don't show anything *puh*
But -Djogl.debug.GLBufferObjectTracker=true shows a potential leak.

My application has a user selectable text feature. That means the user can select font, size, color and position of the 2D Text. Every time the user selects a new font or size the textrenderer is beeing destroyed and allocated with the new data.

That's why it is always calling

 if (mPipelinedQuadRenderer == null) {
                    mPipelinedQuadRenderer = new Pipelined_QuadRenderer();
                }

in TextRenderer line 1473.

This causes a call to:
final int[] vbos = new int[2];
gl.glGenBuffers(2, IntBuffer.wrap(vbos));

line 1781:TextRenderer

Those two allocated Buffers are never ever released by glDeleteBuffers. I read here (http://www.java-gaming.org/topics/memory-leak-in-textrenderer/18325/view.html) that it is common practice to have one allocated TextRenderer and reuse it. Actually, I cannot reuse the textrenderer since there is no mothod setFont in TextRenderer.

Is there another possibility to achive this feature or is this just a bug?


TIA
Matthias

Hi

Can't you try to create at most 1 text renderer per font?

Hey Julien,


thanks for your fast answer.
Yes, you are right that's what your provided "patch" did, am I right? A caching mechanism.

Nevertheless, It is not limited in my application that means the user can create a textrenderer from any AWT font. On windows in is also using TTF files. So there is no limit and then multiply it by the sizes. On a vanilla Windows machine with no TTF installed I find approx. 50 ttf's. So multiplying it by let's say 100 different font sizes multiply by 4 font types (normal, bold, cursive, and I cant remember the english word)

50 * 100 * 4 = approx. 20000 possibilities.

Each uses Textures and therefore GPU-RAM. This is pretty bad, since I found that MacOSX doesn't free all textures at the end of a program run. They might say in GPU RAM.

That means even rerunning the software doesn't solve the leak. We have to be able to take care of it.

Actually, I believed that maually calling this would help:
 if( textRenderer!=null )
{
            textRenderer.flush();
            textRenderer.dispose();
            textRenderer = null;
}

After reading your posts on the internet I understood it will not ;) And after reading through the code of TextRenderer I understood why ;) There is no release code for the internal textures. Maybe it is enough to put glDeleteBuffers in the dispose code? From my current point of view I don't understand TextRenderer enough to provide a patch here.

any hints?

regards Matthias

My patch was about the glyph cache.

In my humble opinion, your very last suggestion is good but I need to spend much time in looking at the code to ensure that it wouldn't cause any regressions. You can still give it a try, just build JOGL and let us know. Fill a bug report with a tiny test case (you can reuse an existing one).

Hey Julien,

I'll try my best to build jogl. Actually, I have always been stuck somewhere in the middle ;)
I was never building out of the box for me in the past, so I sticked to the prebuilt binaries.

merry christmas
Matthias

Ohh, this time jogl compiled :)

@Sven: you did this cross compiling stuff for 32 bits on MacOSX on ym reuqest. Do you remember where to specify the SDK path? Currently, I am just compiling the 64 bit path on OSX.