Multiple canvases problem

Hi,

I have problems with multiple canvases, but only when disposing/removing them. In other words, I have small JOGL program that can open multiple canvases and doesn’t have problem with it – until I add the code that disposes of the old canvas (and its corresponding frame) and creates a new one each time a user opens new data file.

	//frame to which canvas is added
	Frame FWindow = new Frame();
	FWindow.addWindowListener( new WindowAdapter() {
    	                      public void windowClosing(WindowEvent e){
   		
                                       // a) creates problems
    		/*
    		canvas.removeGLEventListener(listener);
	        	canvas.removeMouseListener(listener);
		canvas.removeMouseMotionListener(listener);
		FWindow.remove(canvas);
    		FWindow.dispose();
    		*/

	// b) no errors
      		System.exit(0);
    	                 }
                                 });

The problem I’m getting in case a) is either

  1. “net.java.games.jogl.GLException: Unable to set pixel format 6 for device context”
    when making frame visible
    FWindow.setVisible(true);

or

  1. Canvas seems frozen and nothing is displayed (on rare occasions it recovers after being minimized, and sometimes it displays data but it doesn’t catch the mouse movements).

I’m using JOGL 1.1.1 version from July 12, 05 on Win XP, with Intel 82852/82855 GM/GME graphics controller.

Please help!!
Anita

Please upgrade to the latest JOGL nightly build and update your application to the new JSR-231 APIs. The 1.1.1 version is obsolete and I can’t hazard a guess as to whether this is a bug in that version of JOGL or something else going wrong.

It would also help to know whether the demos.testContextDestruction.TestContextDestruction demo from the current jogl-demos build works or fails in a similar way on your graphics card.

Hi,

I am having the same problem with the above chipset, see http://www.java-gaming.org/forums/index.php?topic=12652.0. I’ve recently encountered other problems (visual artefacts with basic texture mapping), so I think the Intel drivers are pretty crappy, to be honest! Sorry…

Are there feedback mechanisms where you can file bugs with Intel about these problems? I would really encourage you to do so so that hopefully their drivers improve in the future.

Just a short note, we are experiencing the same issue on a Dell Latitude with an ATI Mobility Radeon (can’t remember the exact model), latest drivers from the Dell website. On that system however the issue appears far less frequent. I’ll see whether I get the time to try and reproduce this problem with lwjgl’s AWTCanvas, as you had suggested in my other post.

Apologies for taking over this thread ::). I guess I could start a new one, however the problem described in the initial post relates to this.

Ken, I have now written up a test case for this, more precisely one using GLCanvas/GLEventListener (i.e. JOGL) and another using LWJGL’s AWTGLCanvas. Apart from those differences, the test cases are identical.

Anyhow the bad news is that it only takes 2 or 3 attempts to break the JOGL test case, where it barfs the SetPixelFormat() error. The LWJGL test case OTOH is reasonably stable, only once did I get the PF error. Both tests were run under similar conditions, on the Intel 82855 hardware.

I’m sure this is down to a weakness in Intel’s driver, and I’ll try and chase them up. In the meantime would there be any chance to revisit the context handling in JOGL to see whether anything could be done. I would really appreciate that!

Thanks,
Matt.

First, thanks for the test case.

I’ll try to track down some comparable hardware to see if I can reproduce the failure in-house. I would really like to get to the bottom of this as others have recently reported other problems on similar hardware, and the problem isn’t apparent with other chipsets.

In the meantime, it would really speed up the debugging process if we could do one of three things:

[] If you could make the machine in question available via VNC, that would probably be ideal.
[
] If we could set up a time offline when you are in front of the machine and available via phone or IM, that would vastly speed up the debugging process.
[*] Failing this, if you could run some builds as we try to track down what the fundamental differences are in pixel format and context handling between the two libraries we can iteratively see where the differences are. I have done this in the past and it is fairly painful. I would like to avoid doing it again at all costs.

Please let me know what works for you. Feel free to contact me offline via PM or email.

Also could you please tell me what bit depth your machine is set to? 16-bit? 24-bit? 32-bit?

FYI, mabraham and I have worked together to devise a workaround for the issues of creating and disposing multiple GLCanvases on Intel graphics hardware. The underlying issue does appear to be a driver bug but there seems to be a fairly straightforward workaround for it which has been checked in to the JOGL source tree. This fix will be available in the nightly builds dated 3/29 or later and also in the forthcoming JSR-231 beta 4.

thx!! :slight_smile: your work is appreciated.