Gbui in an applet

Hello everyone!



I've been having some issues with gbui in an applet with jme2 that I seem to have solved, but in a rather strange manner. I was hoping to get some insight on this.



I'm trying to use the gbui system by drawing directly on the glCanvas of my jme applet (I simply changed it to protected from private in the SimpleJMEPassApplet class).



CanvasRootNode c = new CanvasRootNode(glCanvas);



I used the same set of windows as in the gbui examples, and they displayed correctly, as I expected them to.

But when I closed (or maximized) them I got several nearly identical null pointer exceptions, usually like 5:


java.lang.NullPointerException
   at org.lwjgl.opengl.GL11.glDeleteTextures(GL11.java:716)
   at com.jme.scene.state.lwjgl.LWJGLTextureState.deleteAll(LWJGLTextureState.java:2112)
   at com.jme.scene.state.lwjgl.LWJGLTextureState.deleteAll(LWJGLTextureState.java:2074)
   at com.jmex.bui.BImage$1.releaseTextures(BImage.java:400)
   at com.jmex.bui.BImage.releaseTexture(BImage.java:366)
   at com.jmex.bui.BImage.release(BImage.java:342)
   at com.jmex.bui.text.AWTTextFactory$1.wasRemoved(AWTTextFactory.java:340)
   at com.jmex.bui.Label$Text.wasRemoved(Label.java:654)
   at com.jmex.bui.Label.wasRemoved(Label.java:174)
   at com.jmex.bui.BLabel.wasRemoved(BLabel.java:168)
   at com.jmex.bui.BContainer$3.apply(BContainer.java:344)
   at com.jmex.bui.BContainer.applyOperation(BContainer.java:402)
   at com.jmex.bui.BContainer.wasRemoved(BContainer.java:342)
   at com.jmex.bui.BContainer$3.apply(BContainer.java:344)
   at com.jmex.bui.BContainer.applyOperation(BContainer.java:402)
   at com.jmex.bui.BContainer.wasRemoved(BContainer.java:342)
   at com.jmex.bui.BWindow.setRootNode(BWindow.java:226)
   at com.jmex.bui.BRootNode.removeWindow(BRootNode.java:177)
   at com.jmex.bui.BWindow.dismiss(BWindow.java:146)
   at com.jmex.bui.listener.CollapsingWindowListener.close(CollapsingWindowListener.java:80)
   at com.jmex.bui.listener.CollapsingWindowListener.actionPerformed(CollapsingWindowListener.java:48)
   at com.jmex.bui.event.ActionEvent.dispatch(ActionEvent.java:47)
   at com.jmex.bui.BComponent.dispatchEvent(BComponent.java:739)
   at com.jmex.bui.BButton.dispatchEvent(BButton.java:190)
   at com.jmex.bui.BRootNode.dispatchEvent(BRootNode.java:457)
   at com.jmex.bui.BComponent.emitEvent(BComponent.java:993)
   at com.jmex.bui.BButton.fireAction(BButton.java:238)
   at com.jmex.bui.BButton.dispatchEvent(BButton.java:171)
   at com.jmex.bui.BRootNode.dispatchEvent(BRootNode.java:457)
   at com.jmex.bui.CanvasRootNode.mouseReleased(CanvasRootNode.java:93)
   at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:273)
   at java.awt.Component.processMouseEvent(Component.java:6041)
   at java.awt.Component.processEvent(Component.java:5806)
   at java.awt.Component.dispatchEventImpl(Component.java:4413)
   at java.awt.Component.dispatchEvent(Component.java:4243)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)



Aside from these exceptions, the windows closed just fine. When maximizing, however, there were issues (the window started to blink and not display some of it's text).

So I went to the almost-top of the stack trace and poked around with the releaseTexture call, as it seemed the problem was simply that the release event of the mouse was being handled more than once.

So, I checked if this was in fact the case with a trivial little hack (which is commented out in this code piece):


    protected static TexturePool _texturePool = new TexturePool() {
//       public int j = 0;
        public void acquireTextures(TextureState tstate) {           
            //System.out.println(j++);
            //if(j++ < 1)
            tstate.apply(); // preload
           
        }

//        public int i = 0;
        public void releaseTextures(TextureState tstate) {           
           //System.out.println(i++);
           //if(i++ < 1)
            tstate.deleteAll();
        }
    };



The println showed that these calls did in fact take place more than once. Also, the tstate.getNumberOfSetTextures() always returned 1, despite the deleteAll() calls.

I got it to work by accident when I left the println (in which i/j was incremented) before the if. No exceptions thrown, and everything closed/maximized as expected - even though it never got to the tstate.deleteAll() call. So I commented it out and now the GUI works, which seems rather strange to me.

Is there a more stable way to make this work in an applet? If not, I figured I could save someone else some poking around by posting this solution, even though it is kind of ugly. Perhaps drawing on the applet's canvas is not the best idea? Is there a better way?

And perhaps someone knows why the various input events are being handled more than once? Any insight would be greatly appreciated.

Thanks :).

Very intriguing.  I've used GBUI in several Applets, but not since JME2.  All of mine were JME1.0 or 1.1.



Send me your code for this Applet and I'll run it through the rigors.



Just to make sure of everything: You're using GBUI from the trunk tip and JME2.



my email is standtrooper AT gmail DOT com



As soon as I get it, I'll hook it up to the GBUI Labs supercomputer and see what's going on.



timo

Correct, I'm using GBUI from the trunk, and JME2.  GBUI has been set up according to the instructions of setting it up in eclipse, JME2 has a modified com.jme.util.Debug class with the debug values set to true, because they wouldn't automatically get that value in an applet for a reason I didn't care enough to investigate.



Email sent; thanks :).