Pbuffer.getCapabilities not fully initialized on some supported adapters?

[scifan]

We are using LWJGL via the JME3 project and observe that, during initialization, Pbuffer.getCapabilities() returns a 0 on some adapters that pass LWJGL and JME3 tests and support LWJGL Displays in other tests.  The same test code returns a value of 1 on faster adapters (6 test systems listed below).  This results in the SAME JME3 applications (7 test applications listed below) failing to initialization on supported (lesser) adapters but operating as intended on more capable adapters.  We suspect that a race condition exists during the initialization of the Pbuffer but have been unable to to definitively locate it within the lwjgl or JME3 code.  Errors reported by JME3 have included ‘Pixel format not supported’, ‘Failed to create display’ and ‘Pixel format not accelerated’. We are asking for ideas in this forum because the first indication of a pending failure is when Pbuffer.getCapabilities() returns a zero value on the slower (GL2 supporting) adapters.  Is there a test we could use to determine if the attributes of the Pbuffer have been set before calling getCapabilities()?  If Pbuffer.getCapabilities() returns a 0, is there a way to test if Pbuffer has been fully initialized?

The table below recaps 7 tests on 6 systems that demonstrate our thinking:
Test 1,2,3: all hardware CAN display JME3canvases/panels
Test 4,5: JME3 in our app can ONLY run on faster adapters using a canvas or panel
Test 5: The problem occurs with simplified version of SDK topcomponent/application
Test 6,7: AWTTestPanel can ONLY run on faster adapters â€" regardless of whether it is running from Installer.java in the SDK project or our app (eliminates our app/project as culprit).

NOTE: All graphics drivers have been updated from the graphics vendor directly. All platforms successfully run AwtTestPanels and TestSafeCanvas via (modified) TestChooser.

                   1 2 3 4 5 6 7         A ‘Y’ indicates that the JME3 canvas/panel
PC               â€"â€" Test â€"â€"-      was visible and interactive
Desk1         Y Y Y Y Y Y Y
Desk2         Y Y Y Y Y Y Y
Desk3         Y Y Y N N ? ?
Laptop1      Y Y Y N N N N
Laptop2      Y Y Y N N N N
MacLaptop  Y Y Y N N ? ?

Tests
1. AwtTestPanels / modified TestChooser (LWJGL Display in AWT Panel)
2. TestSafeCanvas / TestChooser            (LWJGL Display in Swing Canvas)
3. JME3/SDK (using AWT panels)
4. Our app using Swing Canvas context
5. Our app using a reduced SDK SceneViewerTopComponent / SceneApplication.
6. AwtTestPanels from Installer.java of our app (before our code can go wrong)
7. AwtTestPanels from Installer.java of SDK (before your code can do something right)

Desktop 1: Windows 7/64, NVIDIA GeForce 8800
Desktop 2: Windows XP, NVIDIA Quadro 4000
Desktop 3: Linux, NVIDIA GTX 480
Laptop 1: Windows XP, Mobile Intel 4 Series Express Chipset
Laptop 2: Windows XP, Mobile Intel 945 Express Chipset
MacLaptop: OS 10.6, 2006 era adapter that supports GL2.x

A minimal test system to reproduce the first indication of the pending error (we can find) has been reduced to inserting the following two lines into LwjglOffscreenBuffer.java as the first two lines in InitInThread():
System.out.println("LwjglOffScreenBuffer.initInThread Thread: "+           Thread.currentThread().getName());System.out.println("LwjglOffScreenBuffer: Pbuffer.getCapabilities:"+           Pbuffer.getCapabilities());


Things we’ve tried without success:
- Instantiate LWJGL Sys in Installer, access PBuffer from topcomponent later
- Pause/sleep within LwjglOffscreenBuffer.InitInThread() to buy time for PBuffer
- Wait for PBuffer to return getCapabilities=1 (now seems goofy)
- Separate worker thread to run context.create() (now seems goofy)

Extra info ===============================
Desktop 1: output excerpt from SDK showing successful instantiation
INFO [com.jme3.system.lwjgl.LwjglOffscreenBuffer]: Using LWJGL 2.8.2
INFO [com.jme3.system.lwjgl.LwjglOffscreenBuffer]: Offscreen buffer created.
INFO [com.jme3.system.lwjgl.LwjglContext]: Adapter: nvd3dumx,nvwgf2umx,nvwgf2umx
INFO [com.jme3.system.lwjgl.LwjglContext]: Driver Version: null
INFO [com.jme3.system.lwjgl.LwjglContext]: Vendor: NVIDIA Corporation
INFO [com.jme3.system.lwjgl.LwjglContext]: OpenGL Version: 3.3.0
INFO [com.jme3.system.lwjgl.LwjglContext]: Renderer: GeForce 8800 GT/PCI/SSE2
INFO [com.jme3.system.lwjgl.LwjglContext]: GLSL Ver: 3.30 NVIDIA via Cg compiler
INFO [com.jme3.system.lwjgl.LwjglTimer]: Timer resolution: 1,000 ticks per second
INFO [com.jme3.renderer.lwjgl.LwjglRenderer]: Caps: [FrameBuffer, FrameBufferMRT, FrameBufferMultisample, TextureMultisample, OpenGL20, OpenGL21, OpenGL30, OpenGL31, OpenGL32, ARBprogram, GLSL100, GLSL110, GLSL120, GLSL130, GLSL140, GLSL150, VertexTextureFetch, TextureArray, TextureBuffer, FloatTexture, FloatColorBuffer, FloatDepthBuffer, PackedFloatTexture, SharedExponentTexture, PackedFloatColorBuffer, TextureCompressionLATC, NonPowerOfTwoTextures, MeshInstancing, VertexBufferArray]

[Momoko_Fan]

Is there a way to perhaps reproduce this issue without any jME3 code?

[scifan]

Thanks for the idea.  We find that LWJGL demo codes run fine on ALL platforms we've tested.
For example, PBufferTest and others run on each of our test platforms and we are unable to get them to fail.
The other large package involved is netbeans - but we think we have eliminated its effects by demonstrating that the JME3 SDK runs correctly.
I would be glad to code further test cases to localize the problem if you have suggestions.