Bug 72 - Memory Leak Manually Calling repaint()
Summary: Memory Leak Manually Calling repaint()
Status: VERIFIED WORKSFORME
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 1
Hardware: All windows
: P1 normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2004-04-10 11:14 CEST by Sven Gothel
Modified: 2010-03-24 07:46 CET (History)
0 users

See Also:
Type: DEFECT
SCM Refs:
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2010-03-24 07:46:25 CET


---- 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