Using jogl-2.0rc5 (the latest version available, as far as I understand it), I get an exception initializing things. I first encountered this in a local application with relaxed security constraints, but could reproduce it as well in my browser using the Gears demo applet. javax.media.opengl.GLException: X11GLXDrawableFactory - Could not initialize shared resources for :0 at jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:267) at jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:261) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.NullPointerException at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:419) at jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:246) ... 2 more #### Java Web Start Error: #### Profile GL_DEFAULT is not available on X11GraphicsDevice[type X11, connection :0, unitID 0, handle 0x0], but: [] Sounds to me as if this shouldn't happen this way. A null pointer might be an indication of a problem, but if so, I'd hope for the relevant code to check that condition and throw some more informative exception. So I doubt that it's an external problem here. After all, the Gears applet doens't require any exotic capabilities, does it? I used to have older versions of jogl working fine, so my graphics setup should work well enough.
Hi Do you reproduce this bug with the latest autobuild (JOGL build 699)? Please tell me more about your hardware, I don't reproduce this bug on Cent OS 5.3 with an Intel 64 bits microprocessor and a graphics card NVIDIA Quadro FX.
Using GLProfile.getMaxFixedFunc(true) instead of GLProfile.getDefault() might work.
I am on it - thx. 'misio-it' reported the same NPE/GLProfile missing: - GL_RENDERER Mesa DRI Intel(R) 945GM x86/MMX/SSE2 - GL_VERSION 1.4 Mesa 8.0.1 - GL_VENDOR Tungsten Graphics, Inc
The following configuration have passed, hence it's highly probably related to Mesa 8.0.1 and it's OpenGL 3.0 enabled glXCreateContextAttribsARB GL_VENDOR Tungsten Graphics, Inc GL_RENDERER Mesa DRI Intel(R) Sandybridge Desktop GL_VERSION 2.1 Mesa 7.11 GL_VENDOR Mesa Project GL_RENDERER Software Rasterizer GL_VERSION 2.1 Mesa 7.11.2
I haven't had time to test this with local access to the hardware where I first encountered this, but I can confirm this is Mesa 8.0.1 as well. OpenGL vendor string: nouveau OpenGL renderer string: Gallium 0.4 on NV84 OpenGL version string: 2.1 Mesa 8.0.1 Will try to check this getMaxFixedFunc tomorrow.
http://jogamp.org/git/?p=jogl.git;a=commit;h=7a40768455342ab2d1d43bf435baa42a8ccaf917 Fix bug 564 (X11 Mesa 8.0.1 GL 3.0 w/o GLX_ARB_create_context) X11/Mesa 8.0.1 offers a GL 3.0 context w/o having the GLX_ARB_create_context extension available (even though the func-ptr glXCreateContextAttribsARB is not null). We assumed that if no GLContext device availability is set, it can be only GL 2.0 or ES1/ES2. Fix: Relaxed these (false) constrains and map the created context reflecting using it's actual attributes.
Zeno said that the latest fix isn't enough, he provided another one: http://forum.jogamp.org/libgl-version-8-issues-no-profiles-available-tp3832159p3840554.html
Thanks to Zeno's report and analysis, here is the 2nd bug fix regarding a 'broken' ARB_create_context impl: <http://jogamp.org/git/?p=jogl.git;a=commit;h=42c461a157bbcf9e7268b171a7593c2b3ae6a173> Fix bug 564 - part 2 (X11 Mesa 8.0.1 GL 3.0 w/ failing GLX_ARB_create_context) Tolerate a buggy ARB createContext impl (always failing to create a context). Now we only reset the GLContext state and set the context/device availability flag if ARB create context actually was successful. Otherwise the fallback 'old' context is being used w/o having it's context state cleared and context/device availability is set later on. This makes the general use of ARB_create_context more stable. +++ Minor changes: - Non compatibility fallback: Try forward context instead. - Limit ARB context 'seeking' to >= OpenGL 2.0
(In reply to comment #8) > Minor changes: > > - Non compatibility fallback: Try forward context instead. > - Limit ARB context 'seeking' to >= OpenGL 2.0 Why limiting ARB context seeking to >= OpenGL 2.0? Sorry for my silly question.
(In reply to comment #9) > (In reply to comment #8) > > Minor changes: > > > > - Non compatibility fallback: Try forward context instead. > > - Limit ARB context 'seeking' to >= OpenGL 2.0 > > Why limiting ARB context seeking to >= OpenGL 2.0? Sorry for my silly question. B/c the ARB createContextAttribARB method was introduced with GL 3.1. If available we can assume GL 2.1 (at least 2.0) is implemented or it just doesn't work (Mesa8). Traversing all down to GL 1.1 is sort of futile here, nevertheless GL 1.1 will be caught via the tradition createContext method.