---- Reported by sunsett 2004-04-10 11:14:47 ---- When a frame is visible and repaint() is being called manually the memory usage continues to increase until it is minimized or closed. This needs to be dealt with immediately as any games that expect long-term playing will eventually run out of memory. Please see the following example code that shows this: import java.awt.*; import java.awt.event.*; import javax.swing.*; import net.java.games.jogl.*; public class TestJOGL extends WindowAdapter implements GLEventListener{ private GL gl; private GLDrawable drawable; private Animator animator; private Thread updater; private GLCanvas canvas; public static void main(String args[]) throws Exception { new TestJOGL(); } public TestJOGL() throws Exception { JFrame frame = new JFrame("Test JOGL"); frame.setSize(512, 384); GLCapabilities capabilities = new GLCapabilities(); capabilities.setRedBits(8); capabilities.setBlueBits(8); capabilities.setGreenBits(8); capabilities.setAlphaBits(8); this.canvas = GLDrawableFactory.getFactory().createGLCanvas (capabilities); canvas.addGLEventListener(this); frame.add(canvas); frame.addWindowListener(this); frame.setVisible(true); updater = new Thread() { public void run() { try { int sleep = 1000 / 60; while (true) { canvas.repaint(); Thread.sleep(sleep); } } catch(InterruptedException e) { e.printStackTrace(); } } }; updater.start(); } public void init(GLDrawable drawable) { this.gl = drawable.getGL(); this.drawable = drawable; drawable.setGL(new DebugGL(drawable.getGL())); System.out.println("Init GL is " + gl.getClass().getName()); } public void display(GLDrawable drawable) { gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); gl.glLoadIdentity(); gl.glColor3f(0.5f, 0.0f, 0.0f); gl.glBegin(GL.GL_TRIANGLES); gl.glVertex3f(0.0f, 0.0f, 0.0f); gl.glVertex3f(1.0f, 0.0f, 0.0f); gl.glVertex3f(1.0f, 1.0f, 0.0f); gl.glEnd(); gl.glColor3f(1.0f, 0.5f, 0.0f); gl.glBegin(GL.GL_TRIANGLES); gl.glVertex3f(0.0f, 0.0f, 0.0f); gl.glVertex3f(-1.0f, 0.0f, 0.0f); gl.glVertex3f(-1.0f, -1.0f, 0.0f); gl.glEnd(); gl.glColor3f(0.0f, 0.0f, 1.0f); gl.glBegin(GL.GL_TRIANGLES); gl.glVertex3f(0.0f, 0.0f, 0.0f); gl.glVertex3f(-1.0f, 0.0f, 0.0f); gl.glVertex3f(-1.0f, 1.0f, 0.0f); gl.glEnd(); gl.glColor3f(1.0f, 0.0f, 1.0f); gl.glBegin(GL.GL_TRIANGLES); gl.glVertex3f(0.0f, 0.0f, 0.0f); gl.glVertex3f(1.0f, 0.0f, 0.0f); gl.glVertex3f(1.0f, -1.0f, 0.0f); gl.glEnd(); } public void reshape(GLDrawable drawable, int x, int y, int width, int height) { System.out.println("Reshape called!"); } public void displayChanged(GLDrawable drawable, boolean modeChanged, boolean deviceChanged) { } public void windowClosing(WindowEvent e) { updater.stop(); System.exit(0); } } ---- Additional Comments From kbr 2004-04-10 18:24:43 ---- There is definitely a slow memory leak but it isn't clear where it is. It does not appear to be a leak in the Java heap as -verbose:gc does not show any growth. Most likely the leak is in either the code that interacts with the JAWT or in the JAWT implementation itself, though this is hopefully unlikely. Should run this test on X11. ---- Additional Comments From kbr 2004-04-11 11:33:21 ---- Upon further investigation I can not reproduce this problem. The memory usage of the application starts at roughly 18800K and grows within the first couple of minutes to about 19500K, but then stabilizes. Adding the ability to do a full GC upon a keypress didn't change the behavior, so this growth isn't due to finalizable or reference objects that need to be cleared / cleaned up in order to reclaim native machine resources. Windows XP Professional, NVidia GeForce Quadro FX 700 Go, 44.24 drivers. Please reopen this bug or start a new bug with complete OS, graphics card, and driver information if you see different behavior. --- Bug imported by sgothel@jausoft.com 2010-03-24 07:46 EDT --- This bug was previously known as _bug_ 72 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=72