Restart JMECanvas in SwingGUI


I use a jme canvas with SwingGui (similar to /jmetest/util/

I want to restart the canvas (and so the scene itself) when a button is pressed.

First i thought renderer.reinit(width,height) is what i search for, but that just resize it.

What is the prefered way to restart a scene ?

All i found is in BaseSimpleGame:

    protected void quit() {
        System.exit( 0 );

But i don't want to kill the JVM, just restart the scene (shutdown and reinit)

How do i shutdown and reinit a szene ?

I found no hint in the sources of the JMECanvasImplementor, SimpleGame, BaseGame, BaseSimpleGame or in LWJGLDisplaySystem.

Here in forum i found some hints to a shutdown method:
Is that the way ? And if so, how can i reinit the scene ?

Or is there an other way to restart a JMECanvas ?


i tried it now that way:

  1. cleanup the scene


2. delete canvas from gui


3. recreate canvas (like in SwingGui example in jmetest/utils/)


            // make the canvas:
            canvas = DisplaySystem.getDisplaySystem("lwjgl").createCanvas(width, height);
            // add a listener... if window is resized, we can do something about it.
            this.keyEvents=new ComponentAdapter() {
                public void componentResized(ComponentEvent ce) {
            // Mauseingaben an den 3D Frame routen.
            KeyInput.setProvider( KeyInput.INPUT_AWT );
            AWTMouseInput.setup( canvas, false );
             // Hier wird die 3D Szene initalisiert.
            impl = new CanvasJME(width, height,this);
            JMECanvas jmeCanvas = ( (JMECanvas) canvas );
            jmeCanvas.setUpdateInput( true );

i get an error when doing step 2:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
   at org.lwjgl.opengl.AWTGLCanvas.paint(
   at org.lwjgl.opengl.AWTGLCanvas.update(
   at sun.awt.RepaintArea.updateComponent(
   at sun.awt.X11.XRepaintArea.updateComponent(
   at sun.awt.RepaintArea.paint(
   at sun.awt.X11.XComponentPeer.handleEvent(
   at java.awt.Component.dispatchEventImpl(
   at java.awt.Component.dispatchEvent(
   at java.awt.EventQueue.dispatchEvent(
   at java.awt.EventDispatchThread.pumpOneEventForFilters(
   at java.awt.EventDispatchThread.pumpEventsForFilter(
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(
   at java.awt.EventDispatchThread.pumpEvents(
   at java.awt.EventDispatchThread.pumpEvents(

seems like the event handler of the swing gui has a problem when i remove the canvas.I was not able to figure out how to clean the eventQueue.

By ignoring this problem this seems to be a good way to me. Am i a noob, or is this a way to go ?

or by avoiding the repaint call on the canvas (done in a separate thread in 1.0

Thanks for that suggestion, When i suspend the thread of repainting the problem is done !

That leads me to another question: The example in jmetest/utils/JMESwingTest run the thread on and on, so one cpu core is under full load.

Isn't it a better solution to call canvas.repaint on the end of the render method ? Or to suspend the thread after repaint instead of yield, and make a wakeup in the render method ?

I wonder if it should be that the painting thread completly uses one cpu core (load 1.0) just for its job to repaint . . .

Is there a reason not to suspend and wakeup the thread per Frame ?

The javadoc tells suspend and resume are deprecated because they are deadlock-prone.  (same for stop).

I made a new thread to discuss that: (seems offtopic here)

I don't believe you will run into any big problem by ignoring the queued up paint's NPE.  You may be able to eliminate it by cleaning up the canvas inside the paint thread in some special order or by avoiding the repaint call on the canvas (done in a separate thread in 1.0, or inside the super class in 2.0)

2.0 actually has no thread… it just calls repaint after paintGL is done.  As for stopping/suspending the thread, I'd suggest using a flag instead that you can set to allow the thread to naturally finish (or to skip painting)