GLCanvas/GLJPanel problems

Hi,

I'm working on porting some OpenGL/C++ code to JOGL.

First, I started out using the GLCanvas, and things worked fine - until V2.0-rc11.

Now, my GLCanvas is part of JSplitPane, and when I change the split, I get a:

javax.media.opengl.GLException: Unable to create temp OpenGL context for device context 0x4e0138c3
        at jogamp.common.awt.AWTEDTExecutor.invoke(AWTEDTExecutor.java:58)
       
This happens shortly after dispose(...) is called. This used to work on V2.0-rc10. The crash only happens on Windows, not on Mac.

Now, I tried switching to GLJPanel, and the code works again (probably because dispose() is no longer called when moving the split).

But GLJPanel has other issues:

When using GLCanvas, I get close to 60FPS no matter what the windows size is (even I use a FPSAnimator with higher target FPS, the FPS seems capped to 60FPS).

When using GLJPanel, I get around ~100FPS for a small window sizes, but for large panel sizes, the frame rate decreases down to ~30 FPS. Even with no drawing operations.

My questions:

1) What can I do to avoid the exception, when using GLCanvas? (This is only present on Windows)
2) Why does the frame rate fall when enlargening the window, when using GLJPanel? (This happens on both Windows and Mac)
3) What is the prefered component, GLCanvas or GLJPanel? I need to use it in an application with lots of Swing components.


Best regards, Mikael.

Hi

I get this exception under Windows only when I try to manipulate contexts on the wrong thread. Can you try to find in which version the regression occurs (more precisely than RC11)?

On 11/13/2012 04:41 PM, mikaelhc [via jogamp] wrote:> Hi, A longer trace would have helped more ..
Also you could enable the debug flags -Djogl.debug=all, .. etc see Wiki/FAQ/Debug.

I fixed a regression already, thanks to AC: d0f91a8ed17fbb1a7b56511c4e53a29e576f01af
Also commit c002e04f848116922a1ed7bd96ead54961649bbd etc .. may help in case
you need to remove a GLEventListener incl. it's disposal.
 
Also - pls provide a unit test, so we have a chance to fix it.

Best: Open new bug (Regression w/ _something_smart_here_),
      add all this text to it and attach your unit test (maybe a git email patch?).

If you are unsure how to write a unit test, you can look at the many
we have in jogl/src/test/**.
Maybe you can copy and rename TestJScrollPaneMixHwLw01AWT
and make it suitable to your needs.

Otherwise, simply create a very small application which reproduces the failure.

On 11/14/2012 01:54 AM, gouessej [via jogamp] wrote:
> Hi
>
> I get this exception under Windows only when I try to manipulate contexts on
> the wrong thread. Can you try to find in which version the regression occurs
> (more precisely than RC11)?

Yes that would be great of course.

~Sven

On 11/13/2012 04:41 PM, mikaelhc [via jogamp] wrote:
>
> When using GLCanvas, I get close to 60FPS no matter what the windows size is
> (even I use a FPSAnimator with higher target FPS, the FPS seems capped to 60FPS).

That is simply v-sync enforced.
Depending on your GL profile, OS and desktop - and your driver settings,
v-sync has some defaults.

Hence you can try setting 'gl.setSwapInterval(0)'
in your init or reshape method.

>
> When using GLJPanel, I get around ~100FPS for a small window sizes, but for
> large panel sizes, the frame rate decreases down to ~30 FPS. Even with no
> drawing operations.

Yeah, that's ok. I.e. no v-sync and performance is CPU or memory transfer
bound depending on the composition technique used for that swing panel,
i.e. reusing swing's FBO, own FBO and manual copy pixels .. etc.
In short: For high performance, GLJPanel shall be avoided.

~Sven

Hi,

Thanks a lot for the quick feedback and information!

I've created a small program that reproduces the behaviour: http://pastebin.com/Ys62kjKc

And enabled the debug logging (creates a lot of exceptions):
Log at program startup: http://pastebin.com/DCzbtRT8
Log when resizing (and crashing): http://pastebin.com/Z1kcyGZA

If it is necessary, I can create an unit test, and go hunting for the exact revision of the regression.
But I'm new to Java, so it will take quite some time for me to set up.

I'm not even sure it is a bug: looking at the unit test you suggested, I can see some warnings about mixing hw/lw components. And I guess that is exactly what I do in the JSplitPane. It did work under RC10, though.

Also, I'm not familar with the threading model under Java and JOGL yet. I guess the FPSAnimator runs in its own thread, but it is supposed to automatically invoke the display() calls on the OpenGL thread, I guess?

Regards, Mikael.

Occasionally I experience some other crashes:

java.lang.reflect.InvocationTargetException
Caused by: java.util.ConcurrentModificationException
(Full stack trace: http://pastebin.com/kAtDitFc)

java.lang.reflect.InvocationTargetException
Caused by: javax.media.opengl.GLException: Should not call this
(Full stack trace: http://pastebin.com/ymHEQftP)

But I cannot reproduce these - they just occurs, usually when starting up or resizing component.
Any ideas to why this happens?

As I said, I'm new to JOGL, so I might have missed something fundamental, but I'm having a hard time creating a stable foundation.

The ConcurrentModificationException comes from your source code, maybe you try to modify a list that you're using with an iterator at the same time.

You are of course right about the ConcurrentModificationException, Julien.

The Java threading model confused me. I was doing stuff on the 'main' thread, while the EDT thread was running simultaneously on the same data. I'm used to Qt, where you start the eventloop explicitly at the end of the main thread, so I assumed there would be only one thread actually doing stuff.

What about the other errors? Can you tell whether I'm doing something wrong or if it is JOGL bugs?

The exception whose message is "Unable to create temp OpenGL context for device context 0xe010801" is probably caused by a threading problem in your code too, I fixed something similar in Ardor3D. The OpenGL context must be created and made current on the same thread, this is very important especially with not very tolerant drivers.

I still get the "Unable to create temp OpenGL context for device context" errors.

I wrap everything in an 'invokeLater' call, and, as I understand it, the OpenGL thread should invoke methods on the EDT thread, right?

For instance, the following code crashes when moving the splitter:

public class JoglTest extends JFrame {	
	private static final long serialVersionUID = 1L;

	public static void main(String[] args) {
		SwingUtilities.invokeLater(new Runnable() {
		    public void run() {
		    	new JoglTest();
		    }
		});			
	}
	
	public JoglTest() {
		Container contentPane = getContentPane();
		
		JSplitPane splitPane = new JSplitPane(JSplitPane.HORIZONTAL_SPLIT);
		splitPane.setResizeWeight(0.5d);

		GLCanvas gc = new GLCanvas(new GLCapabilities(GLProfile.getDefault()));
		splitPane.setLeftComponent(gc);
		splitPane.setRightComponent(new JPanel());		
		contentPane.add(splitPane, BorderLayout.CENTER);

		FPSAnimator animator = new FPSAnimator(gc, 100);
		animator.start();
		
		pack();
		setVisible(true);
		setSize(new java.awt.Dimension(824,568));
	}
}

The code works on Mac, and earlier versions of JOGL.

Isn't this a JOGL bug? Or am I missing something?

On 11/20/2012 04:45 PM, mikaelhc [via jogamp] wrote: Please create a bug report and attach your test code to it,
I will have a look at it.

Thank you.

~Sven

Please be very accurate when writing your bug report as I see you use both Windows and Mac, indicate which graphics cards and which drivers you use.

Edit.: Run the pre-beta version of my game. If it works, it means that the bug doesn't come from NEWT, maybe from something related to AWT.

I've created: https://jogamp.org/bugzilla/show_bug.cgi?id=642

gouessej wrote

Edit.: Run the pre-beta version of my game. If it works, it means that the bug doesn't come from NEWT, maybe from something related to AWT.

I don't think it is NEWT related? The bug only occurs using GLCanvas.

I'm going to try to reproduce it under GNU Linux.