-Djogl.1thread=false fails

[technomage]

Using -Djogl.1thread=false does not disable this option (Mac OS/X Radeon 9000 mobility).  This prevents me from using an off-screen context for manipulating buffers or textures.  The amount of work I can do in the main thread is much more limited than what could be done in a background thread.  On my laptop it would not matter so much, but on multi-cpu desktops this is a real issue.  There is the Auto and true settings for the common case where stability is more important than performance, but since my whole reason for using OpenGL is performance, I would like the option to use all available CPUs on such systems.

[Ken Russell]

This system property is available as of JOGL 1.1 b10 and definitely changes the behavior of the single-threaded workaround. -Djogl.1thread=auto will revert the behavior to that of earlier releases, which on your machine (ATI card) will mean that it will be enabled by default. -Djogl.1thread=false will cause the work by display() and reshape() to be done on the threads that invoke them. -Djogl.verbose will confirm whether or not the single-threaded workaround is enabled.

I again strongly recommend you look for other ways to parallelize your application. You will almost certainly run into bugs in Apple's JAWT implementation if you try to render to two contexts managed by the JAWT, which in your case would be two onscreen contexts, from two different threads. You may be able to make pbuffer rendering work in a different thread, but this probably won't be portable.

[technomage]

I have resigned myself to only one thread for on-screen rendering, but I need to be able to update geometry in the background using an off-screen context (pbuffer).  I have the property set to false and my call-back is still on the event thread.  I will enable verbose and see what it says and post that.

Games published by our own members! Go get 'em!

[technomage]

This was due to an older jar/jnilib in an extensions directory.  I hate that.