I have no time to work on my fixes but now, they are stable. Do what you want with them. The only remaining problem is the freeze of the mouse pointer that is not reproducible everywhere. Mathias Henze and me improved the reliability of the JOGL renderer, I hope it will be useful for some guys here. Best regards.
Blaine your jnlp does not work. I receive an exception saying that it cannot find the Spacial class. Did you change something in the webstart? I know I am late to this post, but I am trying to figure out why the AWT InputSystem is not working for me in the latest stable release of jME 2.0.1. I am trying to get away from the lwjgl back end, as I hate the focus stealing nature of it.
P.S. Where is the source for jME3??? I would like to try it out!
realbadapple said:
Blaine your jnlp does not work. I receive an exception saying that it cannot find the Spacial class. Did you change something in the webstart?
Use this launcher. This is no longer just a proof-of-concept and uses the Java 2D pipeline (which you can disable by appending "&pipeline=false" "?pipeline=false", without the quotes, to the URL).
realbadapple said:
I know I am late to this post, but I am trying to figure out why the AWT InputSystem is not working for me in the latest stable release of jME 2.0.1. I am trying to get away from the lwjgl back end, as I hate the focus stealing nature of it.
P.S. Where is the source for jME3??? I would like to try it out!
Search the "JME3 Discussion" forum.
Thanks Blaine! I never scrolled down below the general discussion board on the forum front page. It is a little slow with the java 2D pipeline enabled, but fast without!
P.S. you need to append "?&pipeline=false" not "&pipeline=false" (note the leading '?')!
realbadapple said:
Thanks Blaine! I never scrolled down below the general discussion board on the forum front page. It is a little slow with the java 2D pipeline enabled, but fast without!
P.S. you need to append "?&pipeline=false" not "&pipeline=false" (note the leading '?')!
I was wrong, but it's actually ?pipeline=false. & is for delimiting multiple parameters and there is just one here. (I just corrected it in my original post).
Please report your platform details. I know that on some platforms pipeline has no effect (it's actually disabled in many cases in the JOGL 1.x code), and I know of several cases where it can cause problems or lockup, but I know of no case where it caused anything to run slower.
but it's actually ?pipeline=false
Ya, that is what I meant!
Why aren't our fixes in the latest stable release? Nobody has to fix those bugs once more.
The latest 'stable' release was made in September 2009, these changes came after 
blaine said:
replaced the GLCanvas with a GLJPanel
Hm, doesnt that make the opengl lightweight, running with less performance? If not its kind of a "fake" that its a JPanel..
normen said:
blaine said:
replaced the GLCanvas with a GLJPanel
Hm, doesnt that make the opengl lightweight, running with less performance?
No. "Lightweight" does not imply "less performance". That must be assessed in a case-by-case basis, but if you want a generalization, lightweight variants are more often higher performance than heavyweight because they perform the same amount of output work more efficiently.
normen said:
If not its kind of a "fake" that its a JPanel..
Spend 5 minutes studying the class in the JOGL API spec and you'll see how wrong you are.
blaine said:
No. "Lightweight" does not imply "less performance". That must be assessed in a case-by-case basis, but if you want a generalization, lightweight variants are more often higher performance than heavyweight because they perform the same amount of output work more efficiently.
Spend 5 minutes studying the class in the JOGL API spec and you'll see how wrong you are.
Really eloquent, you managed to not answer my questions while proving me wrong about things I did not say.
So, is it lightweight or not? What I mean by saying that it is "fake" is that putting a heavyweight component on top of a lightweight component and then saying its lightweight is fake. I did not say that you do that though. That was the other question.
And what does "more efficiently" mean? From what I know (and I don't say I know much about OpenGL) a heavyweight component would be the only thing the renderer can access "natively" w/o copying data to the java screen buffers, so is not doing that really efficient?
Cheers,
Normen
What I mean by saying that it is "fake" is that putting a heavyweight component on top of a lightweight component and then saying its lightweight is fake.
That's not what is happening. From an AWT viewpoint, the canvas is a heavyweight component while the jpanel is lightweight, there's no "faking".
what does "more efficiently" mean? From what I know (and I don't say I know much about OpenGL) a heavyweight component would be the only thing the renderer can access "natively" w/o copying data to the java screen buffers, so is not doing that really efficient?
That is the issue, yes. Using the GLCanvas yields more performance because the rendering is done directly to the screen, while a GLJPanel requires rendering the OpenGL content off-screen, copying it to java memory as an image, and then sending it back to the screen. This copying around (esp. the GPU -> CPU) can significantly lower performance when using the JPanel method.
Blaine did avoid this question about OpenGL canvas performance and instead gave a general answer about heavyweight vs. lightweight, not sure why.
sbook said:
The latest 'stable' release was made in September 2009, these changes came after ;)
Ok thanks. I have had only a few problems with some Intel craps until now.