---- Reported by delwarl 2004-12-13 16:10:18 ----

Every time you remove & add a GLCanvas back into a container such as a JPanel, 
you'll lose about 0.6 MB of RAM.  (Hardware: ATI 9700 Pro, Win 2K, 
J2sdk1.4.2_05).

There's a working example downloadable via the URL, but the pertinent lines of 
code are right here:

private GLCanvas canvas;

public void actionPerformed(ActionEvent e) {

  // EVERY REMOVE/ADD CYCLE, WE LOSE ~ 0.5-0.7 MB under Win32
 leaky_panel.remove(canvas); 
 leaky_panel.add(canvas);
 leaky_panel.validate();
}

Having hacked around a bit in the code, I've tracked the loss to the 
WGL.SetPixelFormat call in WindowsGLContext.java, which is called every time a 
new GLContext is realized.  The memory consumed by this call is never restored 
until the process is terminated.



---- Additional Comments From kbr 2004-12-14 15:43:45 ----

There is more information about this issue on the following thread:

http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1102887360;start=0#6

It isn't clear to me at this point how to fix this problem. Creating a new
window inside of the Canvas's HWND will probably present significant problems
with AWT interoperability.



---- Additional Comments From kbr 2005-01-31 01:29:48 ----

After more investigation this problem is not reproducible, at least on my
hardware. I suspect it is once again due to multithreading bugs in ATI's
drivers. The forthcoming JOGL 1.1 b08 (as well as the code in the CVS
repository, if you can build it) will contain more workarounds for these
problems that have proven to be pretty robust with the test cases we have
available. Please retest with this release when it comes out and reopen this bug
or open a new one if problems persist.




--- Bug imported by sgothel@jausoft.com 2010-03-24 07:47 EDT  ---

This bug was previously known as _bug_ 125 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=125