Invalidation of SceneGraph if Netbeans Topcomponent is moved

Troubleshooting graphics
1

Hi JME (and Netbeans) fans,



does anyone of you know how to let the JMECanvas within a Netbeans TopComponent be valid if the Topcomponent is drag and dropped? I use JME 2.0.1 and not JME 3.



Thanks a lot.



Regards,

Equi

2

You could use a lightweight implementation of the canvas (Swing), it should work more smoothly in the NetBeans environment than the heavyweight component. Dont exactly remember where and how, but I know it works somehow with jme2 canvases. However there is a performance cost due to the rendering to memory and copying to swing.

3

Hello,



I don't understand this. As far as I know the JMECanvas is heavyweight. How will you change a heavyweight component to a lightweight component. If this would work many problems could be solved. Did you already do this in the past? If so, I believe you and I'll look for it. If you only think that this works I can't believe it.

However, how about JME3.0 will this problem be solved there?

Thanks,



bye

4

As I said, its rendering off screen and copying to awt and yes, I am sure there are implementations of that for jme2 (I think blaine did one). Jme3 does not support awt lightweight canvas per se but the TestRenderToMemory test does exactly that, displaying the jme3 rendered image in a lightweight awt panel.

5

I am not sure what exactly the issue is here, but using light-weight canvas isn't a good idea in many cases. There's a rather large performance loss associated with it, in high resolution canvases, you gotta copy a lot more data from the video card back and forth which can reduce performance significantly. That's why using light-weight canvases is to be avoided if possible.

However I think it should be allowed to choose either one for whatever use you may come up with, so both types of canvases should be supported by the engine. Perhaps at some later point this feature may be added but for all uses we have for it now we didn't find any issue with heavy-weight canvas.

6

Hello,



yes, thanks, I totally understand that drawing a scene in backbuffer is bad idea due to performance issues. As I already told Normen in another thread, I have got the problem that my scene graph becomes invalidated in any way when the TopComponent of my Netbeans platform is detached, undocked or moved to another position. If someone could tell me how to solve this problem with JME2 I would be TOTALLY happy. When JME3 becomes stable version I'll siwtch to it where the problem should be solved (as far as I understood normen correctly).

Thanks a lot.

7
"Equilibrium" wrote:
Hello,
When JME3 becomes stable version I'll siwtch to it where the problem should be solved (as far as I understood normen correctly).
Thanks a lot.
You should start looking into jme3 soon to avoid switching problems then, some things are quite different than in jme2.
8

You can not imagine how many classes my project already has got. I hope switching will become no problem using search and replace tools. If changing the package name from com.jme.* to com.jme3 is the biggest problem than it's okay. I already tried to switch but found lot more issues. will there be a tutroial for those who switch to jme3?



I already start crying when I think of the work I will have to do…



Would you say that jme3 has got at least the same capabilities than jme2 only with another code syntax?

9

Hi,



OK. I have switch to JME 3 now. Before I rewrite everything from the scratch, I wanted to test the native peer - Swing compatibility, of course. I figured out that nothing changed. I can init my native peer canvas without any problem. Undocking from Netbeans also works (mostly). If I want to dock it back to the Netbeans platform I get something like this.



SEVERE [com.jme3.app.Application]: Failed to parent canvas to display

org.lwjgl.LWJGLException: Could not make context current

        at org.lwjgl.opengl.WindowsContextImplementation.nMakeCurrent(Native Method)

        at org.lwjgl.opengl.WindowsContextImplementation.makeCurrent(WindowsContextImplementation.java:90)

        at org.lwjgl.opengl.Context.makeCurrent(Context.java:182)

        at org.lwjgl.opengl.Display.makeCurrent(Display.java:730)

        at com.jme3.system.lwjgl.LwjglCanvas.createContext(LwjglCanvas.java:243)

        at com.jme3.system.lwjgl.LwjglCanvas.restoreCanvas(LwjglCanvas.java:191)

        at com.jme3.system.lwjgl.LwjglCanvas.runLoop(LwjglCanvas.java:122)

        at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:162)



etc…



any idea how to bypass it this time?



Thanks…

10

For jme3, you can look at jMP and see how the jme3 canvas is started there. The relevant code is in jme3-core, SceneApplication and SceneViewerTopComponent.

11

Hello Normen,



yes thanks. this is exactly what I did. I checked out your source code and looked at it. I also did a startup of your app and it seems as if you can dock and undock the topcomponent without any problem. This is strange. If I look at your code you put the canvas to a JPanel and the JPanel to the topcomponent. I also did this but still have got the problem. Doesn't matter. I'll find out how it works. At least now I know that it can be done. Else it would be wast of time. let's see what happens.



bye

12

OK. I give it up. It doesn't work. I succeedded to make docking and undocking work using the SceneApplication class from Normen but while working with swing errors still occur, e.g. if you try to minimize the window. I'll use the undocked standard frame window beside the netbeans platform. this is the only thing that makes sense. JME ist not compatible with swing and netbeans platform.