Resize problem

There is a "resize" problem with JOGL in Mac OS X.

When I run the following jogl demo it works fine at first. But when I try to resize it the canvas disappears. I just see a blank jpanel in its place.

http://jogamp.org/deployment/jogamp-current/jogl-demos/Gears.jnlp

The Mac OS X version is 10.9.5

which version of java do you use?

Java 1.8.0_45

Did anyone verify this problem?
It's 100% reproduceable in several Mac OS X machines we tested.

This is a serious problem that is preventing us from upgrading from old abandoned Ardor3D to the new JOGL based Ardor3D.

I have failed to upgrade the Macbook Pro Sven gave me, I'm stuck with OS X 10.6.8. Which version of Mac OS X do you use?

Edit.: Is it reproducible with Yosemite?

Edit.: Is it reproducible without Java Webstart?

Please try to find in which version of JOGL this regression appeared. What was the last working version?

My version of Mac OS X is 10.9.5
It also doesn't work on Yosemite 10.10.3

It is indeed reproducible both with and without Java Webstart. Our standalone application has same problem.

I can't pin point exactly which jogl version started having this problem. I can't code and compile in our mac test machines so it's difficult to test different jogl versions. Do you have a site where you archived runnable jogl Gear demos made with older jogl versions? If so I'm happy to test them in our test machines.

On 06/10/2015 06:05 PM, runiter [via jogamp] wrote: Please file a new bug report - and I will have a look into it.
Odd .. since we do have resize unit tests.

Thx for reporting, as usual.

~Sven

Thanks Sven,
Bug report added: https://jogamp.org/bugzilla/show_bug.cgi?id=1161

I tried switching to NEWT instead of JoglAwt to see if that works better in Mac.

Again it worked fine in Windows, but in Mac OS X, the problem got even worse because now it doesn't render anything at all.

This is more an Ardor3D question, but am I doing it right when creating NEWT canvas this way in Ardor3D?

final DisplaySettings settings = new DisplaySettings(400, 300, 24, 0, 0, 24, 0, 4, false, false);
final JoglNewtAwtCanvas canvas = new JoglNewtAwtCanvas(settings, new JoglCanvasRenderer(this));
TextureRendererFactory.INSTANCE.setProvider(new JoglTextureRendererProvider());
mouseWrapper = new JoglNewtMouseWrapper(canvas, new JoglNewtMouseManager(canvas));
keyboardWrapper = new JoglNewtKeyboardWrapper(canvas);
focusWrapper = new JoglNewtFocusWrapper(canvas);

The above code used to work fine in Mac OS X. I wonder if the API has changed since JOGL tookover Ardor3D.

runiter wrote

The above code used to work fine in Mac OS X. I wonder if the API has changed since JOGL tookover Ardor3D.

There has been no noticeable change. Maybe disable the HiDPI under Mac OS X. Your code seems to be correct but creating a TextureRendererFactory isn't mandatory. Are you sure that you want to use 4 samples?

Please try to run a rudimentary example based on JoglAwtCanvas available in ardor3d-examples under OS X, JoglAwtExample.

gouessej wrote

Are you sure that you want to use 4 samples?

What sample number do you recommend? I can't put zero because I enabled anti-aliasing.

gouessej wrote

Please try to run a rudimentary example based on JoglAwtCanvas available in ardor3d-examples under OS X, JoglAwtExample.

I ran the ardor3d example and to my surprise they all ran fine. It's strange that JOGL Gear demo doesn't work, but Ardor3D code that used same JOGL version worked.

Despite the fact that the examples worked I couldn't get my own project to work reliably with NEWT. It works fine 50% of times, and it doesn't render anything at all 50% of times. I have to keep restarting the application to get it to work. Once it works, it will keep working properly until I shut down the program. So the problem seem to be at initialization somewhere.

BUT I finally found a solution for my project. The solution is to use JoglSwingCanvas instead of JoglAwtCanvas or JoglNewtAwtCanvas. Somehow JoglSwingCanvas works reliably in my project.

As I mentioned above, JoglSwingCanvas fixed my previous problem. But it has an new problem.
I notice a ghosting effect in JoglSwingCanvas when I move the objects in the scene. In my program, when the scene is moving I keep rendering but when the scene stops moving I stop rendering. When the rendering is stopped it looks like JoglSwingCanvas combines previous 3 frames into one as shown below (notice the arrows). Is this intentional behavior? How can I fix it?

It's not intentional. You can disable the double buffering. In my humble opinion, you should make it work without interfering with the rendering, by rendering even when the scene isn't moving. Then, when it works, you should test with other canvases too in order to ensure that the problem comes from your own code rather than mine. After that, use your code to stop the rendering when the scene doesn't move.

JoglSwingCanvas is the least performant JogAmp's Ardor3D canvas. I think that your main concern is the poor AWT implementation under Mac OS X, both in Apple and Oracle JREs.

Rendering anew only when it is necessary can help to decrease the energy consumption but it is tricky to implement just right. I don't advise you to do so except for often modified very large meshes. I'm not sure it's worth the efforts in the general case.

gouessej wrote

You can disable the double buffering. In my humble opinion, you should make it work without interfering with the rendering

Thanks. Instead of disabling double buffering I'm gonna try rendering 3 frames after the scene stopped changing. That should fix it.

gouessej wrote

Rendering anew only when it is necessary can help to decrease the energy consumption but it is tricky to implement just right. I don't advise you to do so except for often modified very large meshes. I'm not sure it's worth the efforts in the general case.

We have no choice because otherwise the CPU usage becomes 100% which results in overheating CPU which results in the CPU fan always running fast which is noisy and annoys users.

gouessej wrote

Render even when the scene isn't moving. Then, when it works, you should test with other canvases too in order to ensure that the problem comes from your own code rather than mine.

I tried rendering the scene continuously this and NEWT still not working reliably. Sometimes it works, sometimes it doesn't.

Would you like to take a look at our code? It's opensource here:

https://github.com/concord-consortium/energy3d

Enabling the v-sync should be enough to avoid overheating. Doing something similar for the code targeting the CPU could help.

Ok I can look at your code.

gouessej wrote

creating a TextureRendererFactory isn't mandatory.

Turned out it is mandatory because if I remove TextureRendererFactory.INSTANCE.setProvider() I get the following exception when enabling Bloom effect:

com.jogamp.opengl.GLException: Caught RuntimeException: java.lang.IllegalStateException: No provider has been set on TextureRendererFactory. on thread Energy 3D Application
        at com.jogamp.opengl.GLException.newGLException(GLException.java:76)
        at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1311)
        at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1131)
        at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:680)
        at jogamp.opengl.GLDrawableHelper.invoke(GLDrawableHelper.java:910)
        at jogamp.opengl.GLAutoDrawableBase.invoke(GLAutoDrawableBase.java:603)
        at com.ardor3d.framework.jogl.JoglNewtAwtCanvas.draw(JoglNewtAwtCanvas.java:88)
        at com.ardor3d.framework.FrameHandler.updateFrame(FrameHandler.java:90)
        at org.concord.energy3d.scene.SceneManager.run(SceneManager.java:363)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: No provider has been set on TextureRendererFactory.
        at jogamp.opengl.GLRunnableTask.run(GLRunnableTask.java:66)
        at jogamp.opengl.GLDrawableHelper.execGLRunnables(GLDrawableHelper.java:767)
        at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:675)
        at jogamp.opengl.GLAutoDrawableBase$2.run(GLAutoDrawableBase.java:442)
        at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1277)
        ... 8 more
Caused by: java.lang.IllegalStateException: No provider has been set on TextureRendererFactory.
        at com.ardor3d.renderer.TextureRendererFactory.createTextureRenderer(TextureRendererFactory.java:99)
        at com.ardor3d.extension.effect.bloom.BloomRenderPass.doInit(BloomRenderPass.java:261)
        at com.ardor3d.extension.effect.bloom.BloomRenderPass.doRender(BloomRenderPass.java:136)
        at com.ardor3d.renderer.pass.Pass.renderPass(Pass.java:63)
        at com.ardor3d.renderer.pass.BasicPassManager.renderPasses(BasicPassManager.java:68)
        at org.concord.energy3d.scene.SceneManager.renderUnto(SceneManager.java:441)
        at com.ardor3d.framework.jogl.JoglCanvasRenderer.draw(JoglCanvasRenderer.java:265)
        at com.ardor3d.framework.jogl.JoglDrawerRunnable.run(JoglDrawerRunnable.java:16)
        at jogamp.opengl.GLRunnableTask.run(GLRunnableTask.java:60)
        ... 12 more

Ok sorry.

Actually, nothing forces you to use your frame handler and to update the geometric states each time you call renderUnto(). Doing so and enabling the v-sync should be enough to avoid overheating.

gouessej wrote

Actually, nothing forces you to use your frame handler and update the geometric states each time you call renderUnto(). Doing so and enabling the v-sync should be enough to avoid overheating.

You mean I should call update geometric state each time renderUnto is called or I shouldn't? Currently I only update geometric state when the Mesh changes.

I got a problem with JoglSwingCanvas. Apparently it cannot render bloom effects properly.

Good: Here is what my application looks like with JoglNewtAwtCanvas:


Bad: Here is what it looks like with JoglSwingCanvas:


Looks like a buffering problem in JoglSwingCanvas. Any ideas how to fix that?