Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
|
Hi
Can't you try to create at most 1 text renderer per font?
Julien Gouesse | Personal blog | Website
|
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
|
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).
Julien Gouesse | Personal blog | Website
|
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
In reply to this post by gouessej
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. |
Free forum by Nabble | Edit this page |