JOGL memory leaks!

[rsantina]

Hello, We have an application in my company running on Java3D and now we migrated it to JOGL for performance/memory issues, (Java3D is a general scenegraph that kills performance when large amounts of object manipulation is requested).
JOGL is great wrt Java3D but we are sure that we can get more out of JOGL!

Most of the issues we are facing are observed to be memory leaks mostly with Display list management and 2d rendering. ???

Display Lists:

1- display lists are deleted when canvas is moved/resized.
2- display lists are taking more memory than normal (compared to OpenGL) and its increasing exponentialy.

2D Rendering:

1- the text renderer is heavy and slow when a lot of tags are provided (about 100 strings).

Any help would be appreciated!

[emzic]

hello,

we are also making heavy use of displaylists in our game, but we never got one deleted when moving or resizing the canvas. can you provide a testcase when this happens?
as for the memory leak: are you sure you are not recreating the displaylist all the time?

[cylab]

If you are using GLJPanel, this thread might contain some background to your problem: http://www.java-gaming.org/forums/index.php?topic=18054.0

[rsantina]

@emzic

we are also making heavy use of displaylists in our game, but we never got one deleted when moving or resizing the canvas. can you provide a testcase when this happens?

.

Hello, i found an issue related to this case in one of the forums (cant remember which or what was the case). A test case can be very easy, create a display list and delete object after the display list is sucesfully created. Then undock the canvas from a border layout (if you have other guis), if not go fullscreen on the canvas and you will see that the object is not visible anymore (display lists are deleted).

When i looked at the forums this behaviour was produced from the “feature” of refreshing the canvas when it is changed! Keeping it uptodate!

As for the memory leak can u tell me the magnitude of display lists that you are using cuz in our application is can grow to a million. (if the graphic card cant handle them (old card) the renderer process them normally)!
As for recreating the display lists no im sure not to, but nevertheless in theory and also in OpenGL recreating the display lists will not produce a memory leak since unreferenced blocks would be deleted.

and i am using the heavyweight GLCanvas for performance!

[lhkbob]

@rsantina

Then undock the canvas from a border layout (if you have other guis), if not go fullscreen on the canvas and you will see that the object is not visible anymore (display lists are deleted).

If you undock it (ie its no longer visible since I’m assuming you mean you removed it from its container), removeNotify() is called, which with GLCanvas cleanups up the gl context. Similar behavior probably happens when you move to fullscreen (most likely caused by work-arounds to get java fullscreen to behave better). This is my theory at least, but don’t quote me on it until Ken verifies any of it.

[kbr]

This sounds correct. When you’re using OpenGL with a windowing toolkit like the AWT you need to write your code in such a way that it can deal with having the context destroyed out from under it and recreated. Please read the JOGL Users’ Guide linked from the JOGL home page.

[rsantina]

If I may comment, in OpenGL the data are stored in the graphic memory so when the windowing toolkits like MFC/glut/glu need to refresh they will only refresh the Projection/Modelview matrices and the screen window thus the display lists wont be deleted. I find it as a strange behaviour what is happening with JOGL regarding this issue.

And another question, which relates to the subject of the thread, what is actually happening when yoou create a display list using JOGL because it seems to me that its not the same as OpenGL (in behaviour, performace, and memory footprint). I have seen from some tests ive made that the display lists are taking a huge amount of memory?

[lhkbob]

@rsantina

If I may comment, in OpenGL the data are stored in the graphic memory so when the windowing toolkits like MFC/glut/glu need to refresh they will only refresh the Projection/Modelview matrices and the screen window thus the display lists wont be deleted.

What do you mean by a windowing toolkit needing to refresh? That they redraw something to the framebuffer, backbuffer, etc, or that something closer to the OS happens where they have to be removed and readded to the windowing environment?

Because if all it is redrawing, I’ve never experienced anything that you’re talking about, and if its the other, there are valid reasons for not doing it the way you’d like and plenty of workarounds.

Also, how are you measuring the memory footprint of your display lists?