Resource management

OpenGL Development JOGL Development
#1

Hey,

I’m developing an application that puts a number of GLCanvases into more or less complex layouts. Depending on the state of the application, I want to show or hide specific views. The problem I have is that a GLCanvas that has been realised doesn’t destroy its context when hidden; it appears that this happens only in removeNotify() i.e. when I remove the view from its parent container. Is there a way around this? I am attaching a test case to demo the problem: a JTabbedPane hosting 10 or so GLCanvas instances. Click each tab and you’ll notice that at some point (depending on your gfx hardware I guess), performance drops and the animation becomes very jerky. NB: the underlying CardLayout will hide components for inactive tabs; I have installed a ComponentListener that will remove the corresponding GLCanvas from the animator.

Any help would be much appreciated! Also please shout if you spot any blatant mistakes…
Matt.

#2

I haven’t had a chance to run your test case but this is really an application-level problem. You may be able to do something awful like call GLCanvas.getContext().destroy() (or, more correctly, invoke a Runnable on the OpenGL thread using the Threading class to do this) when you’re sure the context is not current and that the canvas has been hidden. It should probably be automatically recreated the next time the GLCanvas becomes visible. I think from a technical standpoint that should work.

#3

Hi,

There is another issue related to destroying context.

Some (ugly) systems show problematic behavior upon application exit if GLCanvas has not been removed from container frame prior to call to System.exit(). For example, VIA EPIA-M board with latest drivers works this way (screen freezes on app exit, even other Windows apps incl. Explorer don’t show up), as well as some of rare panel PCs I had for test. At least once it has been seen on Intel 855GM-based board with on-board dual-head graphics. Workaround for this is pretty easy to implement and simple, but would be nice that at least System.exit works correct :slight_smile:

My question is: shouldn’t JOGL automatically destroy allocated contexts on System.exit?

Yuri

#4

JOGL shouldn’t need to shut down cooperatively. The process model on modern OSs and the implementation of the drivers is supposed to handle all of these issues. These clearly sound like driver bugs and should be reported to the various manufacturers.

#5

Ken,

[quote]These clearly sound like driver bugs and should be reported to the various manufacturers.
[/quote]
Yes, this is sure driver bug, and I already reported it. Anyway, it is not so big issue and workaround is trivial, so this is low priority. My previous post was just to highlight possible problems to those who may experience similar problems.

Yuri

#6

Cf. JOGLStressTest.java line 81:


canvas.getContext().destroy();

This does seem aweful to me. But it also makes no difference. I’m not sure why I need to do this anyway. Wouldn’t it be better if JOGL did this automatically when the underlying component is hidden?

Thanks,
Matt.

#7

OK I have now rewritten this to actually remove hidden GLCanvas instances from their parents. However, on at least one of my test machines (Intel 82852/82855 GM/GME), when I run the test case and flick through the tabs I get a GLException “Unable to set pixel format 6 for device context 0x6e010d5f: error code 0”. Could this be a threading issue?

I have attached the modified code and stack trace to this post. Note: this is using the latest nightly build!

#8

How does the demos.testContextDestruction.TestContextDestruction work on that machine when you repeatedly swap the components between the two windows?

Your test case works perfectly on my machine. I think you are running into a driver bug on Intel hardware related to the creation and destruction of multiple OpenGL contexts. Have you upgraded to the latest available drivers for that hardware?

#9

If you’re running on Windows, you should be specifying -Dsun.java2d.noddraw=true on the command line; are you doing this?

#10

Same exception cropping up, eventually. See attached trace. VM args: ‘-Dsun.java2d.noddraw=true -Djogl.debug=true’.

Yes I’m running the latest drivers available from www.intel.com. See attached diagnostic report.

I ought to point out that taking out the animator did not cure the problem, so perhaps you’re right and it is a driver issue.

#11

Sorry, I don’t have a good answer for you. I would suggest you try writing a test with LWJGL’s AWTGLCanvas and see whether it fails in the same way on your Intel hardware. If it does, then it’s definitely a driver problem. If it doesn’t, then please post and we can look into JOGL’s context management further.