Hi,
I’ve refreshed my old game Zoltar’s Return, and put it at JavaPause.com
This game is just now a proof of concept for JOGLAppletLauncher (I don’t plan on improving it) and could be used to try and find bugs related to this technology.
Already tested here with Java 1.4 on mac, and 1.6 on win XP, (there are still some occasional crashes on page exit).
Any feedback welcome !
Lilian 
The game is here : http://www.javapause.com/games/zoltar
Quite a polished proof of concept 
It ran smooth on XP - FF 2.01 - Java 1.5
Only bug I encountered was like you said, when I closed the page…
Yes, I really have to find out why this happens.
Do you have an hs_err_pid file describing the crash ?
(in other news : reported working on mac mini with OS X Tiger (java 5))
Lilian
Yup, I attached the error log
Ken (or anyone else), could you have a look at the error log (from thijs) and suggest me something please ? I’m a bit lost ???
In the game, the canvas is added from the init() method of the applet, and removed from the destroy() method.
The game loop uses the FPSAnimator class, and animator.stop() is invoked from the applet.stop() method. (so everything should happen in the EDT)
I’ve tried to release every display list and texture objects before removing the canvas, but it doesn’t change anything.
I’ve also tried not removing the canvas, but the crash also happens
The strange thing is that the game doesn’t crash on exit when you just display the menu, and then change of page (it starts crashing only when the game has been displayed, even only for a few seconds of play).
I’ve also tried removing sound, but as expected it doesn’t change anything.
I’m sure it’s related to that game (Jack Flower doesn’t crash on exit when played as an applet) but I don’t know why…
Any ideas ?
Lilian
I can reproduce the crash in Mozilla. I tried disabling the talkback agent with no effect.
Looking carefully, I realized that the GLCanvas is actually not being removed on the EDT. It turns out that for historical reasons an applet’s control methods init(), start(), stop(), and destroy() are NOT called from the EDT, but from a newly-created thread called the applet thread. This means that for correct behavior in the current applet implementations you should do any AWT-related work using the EventQueue.invokeAndWait() or EventQueue.invokeLater() methods.
There is a gotcha, though. When the applet’s destroy() method is being called the current thread holds the AWT tree lock so you can’t do an EventQueue.invokeAndWait() call without causing a hang. JOGL tries to move the OpenGL context destruction over to the EDT in GLCanvas.removeNotify() but it can’t do it in all situations, this one in particular.
You may be able to work around this by doing some cleanup work in stop() instead of destroy().
I don’t know why this particular applet provokes a crash and others don’t. Maybe some OpenGL state is not correct and this causes the OpenGL implementation to crash when trying to destroy the associated context. Does DebugGL report anything?
Thanks, I had forgotten about this applet thread,
I’m going to test cleanup from the applet.stop() and see what it does, I’ll report my tests here later
Lilian