Created attachment 174 [details] JOGL Debug Log for X300 GLException "WindowsWGLDrawableFactory - Could not initialize shared resources" since JOGL 2.0.222 on ATI X300 java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.javaws.Launcher.executeApplication(Unknown Source) at com.sun.javaws.Launcher.executeMainClass(Unknown Source) at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) at com.sun.javaws.Launcher.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ExceptionInInitializerError at LedAlex.GIS.GISViewer3D.<init>(GISViewer3D.java:99) at LedAlex.GIS.GISViewer3D.main(GISViewer3D.java:156) ... 9 more Caused by: javax.media.opengl.GLException: WindowsWGLDrawableFactory - Could not initialize shared resources at com.jogamp.opengl.impl.windows.wgl.WindowsWGLDrawableFactory.getOrCreateShared(WindowsWGLDrawableFactory.java:173) at com.jogamp.opengl.impl.windows.wgl.WindowsWGLDrawableFactory.getOrCreateSharedContextImpl(WindowsWGLDrawableFactory.java:182) at javax.media.opengl.GLDrawableFactory.getOrCreateSharedContext(GLDrawableFactory.java:271) at javax.media.opengl.GLDrawableFactory.getIsSharedContextAvailable(GLDrawableFactory.java:246) at javax.media.opengl.GLProfile.initProfilesForDevice(GLProfile.java:1223) at javax.media.opengl.GLProfile.initProfilesForDefaultDevices(GLProfile.java:1172) at javax.media.opengl.GLProfile.access$000(GLProfile.java:66) at javax.media.opengl.GLProfile$1.run(GLProfile.java:107) at java.security.AccessController.doPrivileged(Native Method) at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:105) at javax.media.opengl.GLProfile.validateInitialization(GLProfile.java:1304) at javax.media.opengl.GLProfile.getDefaultDesktopDevice(GLProfile.java:1291) at javax.media.opengl.awt.GLCanvas.<clinit>(GLCanvas.java:86) ... 11 more Caused by: javax.media.opengl.GLException: Error freeing OpenGL context, werr: 0x0 at com.jogamp.opengl.impl.windows.wgl.WindowsWGLContext.releaseImpl(WindowsWGLContext.java:351) at com.jogamp.opengl.impl.GLContextImpl.release(GLContextImpl.java:205) at com.jogamp.opengl.impl.windows.wgl.WindowsWGLDrawableFactory.getOrCreateShared(WindowsWGLDrawableFactory.java:163) ... 23 more
Created attachment 175 [details] SiSoftware Sandra Report on ATI X300 OpenGL Capabilities SiSoftware Sandra Report on ATI X300 OpenGL Capabilities
Same thing happens on ATI X1300
Created attachment 176 [details] JOGL Debug Log for X1300 JOGL Debug Log for X1300 Last ATI drivers installed on this machine
Created attachment 177 [details] SiSoftware Sandra Report on ATI X1300 OpenGL Capabilities SiSoftware Sandra Report on ATI X300 OpenGL Capabilities
Same program works fine on all NVIDIA that i have found around... Exception arises on next code line: 99: private final GLCanvas Canvas = new GLCanvas();
Looks like wglMakeCurrent(0,0), release ctx, returns false with a success windows error value. I added code to tolerate this -> d1d10e7eeb2a46acf16ae125395e95189e011f1f, kicking off autobuild http://jogamp.org/chuck/job/jogl/233/. Please verify, since I don't have this GPU with the old ATI driver.
I have tested new JOGL.2.0.236 build on X300. Now Java VM just crashes without logs together with JavaConsole. To get log I have made system console redirection to file. Program passed previous issue, but now it crashes on next log lines: WindowsWGLContext.createContext failed, fall back to !ARB context 0.0 (old) - @creation WindowsWGLContext.wglMakeContextCurrent: true
Created attachment 181 [details] JOGL 2.0.236 Debug Log for X300 JOGL 2.0.236 Debug Log for X300
Created attachment 182 [details] Java crash report Finally i've got java crash report
Thank you, now I guess it makes sense, ie the ARB .wglMakeContextCurrent somehow does exist, but throws an exception. Now I changed the X11/WGL part of using the 'read drawable' extension GlueGen: e85797b46e52aba51478fbf0af7db1d4ff95febf JOGL: 597007fc23fbf86e036629b6c6b157e0e0506715 Please update and verify .. I will kick off an autobuild now
Just aggregated the latest autobuild 237 http://jogamp.org/chuck/job/jogl/237/ which you can pick up here: http://jogamp.org/deployment/jogamp-next/ http://jogamp.org/deployment/archive/master/gluegen_224-jogl_237/ Please check with you OS/driver combination, it worked for me with - win7, amd cypress - sure :) - winxp, virtualbox - yeah, no read drawable support, all tests passed I like to close this bug.
Created attachment 184 [details] Java windows screenshot I have tried builds 237 and 239. They does not work at all!! Tested on NVIDIA GeForce 7100GS, NVIDIA GeForce GTS 250, ATI Radeon X300. Java windows takes snapshot of OS framebuffer. It seems that windows repaint never happens.
Created attachment 185 [details] Debug log Now it stuck on finishLifecycleAction(com.jogamp.opengl.util.Animator$WaitForStartedCondition): finished - waited true, started: true, animating: true, paused: false, drawables 1
Led, from here on you need a different strategy. Please provide a test case, ie you could use our unit tests or make on up and send it here. As I mentioned, it works for me on eg. GDI software or GL 2.1 emulated dirver.
We changed a bit in the latest commit, please try again with latest and check for 'Realized Drawable' in the debug message, indicating the drawable creation in GLCanvas when size become != 0. However, it seems that the original problem is actually solved now. Laters, Sven
I have tested 242 build on NVIDIA GeForce 7100GS, NVIDIA GeForce GTS 250, ATI Radeon X300. The behaviour of program now fully unpredictable. On all cards we have different behaviour. We can see that in logs. Also Java VM crash without any log occures on ATI Radeon X300. I have found one paradox. My development computer has WinXP x64 & GeForce GTS 250 (and GeForce 9800GT at my home). When I manually load JARs into my NetBeans and add DLLs path to environment variable everything works fine! But then I use the same code via Java Web Start strange things happens. The same code now does not work at all even on my development machine!!! Although it works fine if I use build 236 and any previous. (Java cache cleanup performed each time before test) When I'm trying to use Web Start Extension from "http://jogamp.org/deployment/jogamp-next/" next thing happens: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.javaws.Launcher.executeApplication(Unknown Source) at com.sun.javaws.Launcher.executeMainClass(Unknown Source) at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) at com.sun.javaws.Launcher.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.NoSuchMethodError: com.jogamp.opengl.util.Animator.start()Z at LedAlex.GIS.GISViewer3D.<init>(GISViewer3D.java:361) at LedAlex.GIS.GISViewer3D.main(GISViewer3D.java:167) ... 9 more Very strange 0_0 ... Maybe I'm wrong, but it seems to me that bug really in Web Start ... I'll try to prove my theory by direct launching my application via NetBeans on machine with X300. Unfortunately I don have full access to that machine, but I'll try to make my best... I'm sorry. I did not understand your post "Please provide a test case, ie you could use our unit tests or make on up and send it here.". It'll be nice if you explain that. P.S. My name is Alex (short from Alexander) not Led ;)
Created attachment 189 [details] NVIDIA GeForce 7100GS Forgot to mention that build 240+ succesfully solves problem with window repaint.
Created attachment 190 [details] NVIDIA GeForce GTS250
Created attachment 191 [details] ATI Radeon X300
These are great log files Alexander, thank you. I will dig through the code now, looks like the PFID is not set in your setup.
Created attachment 192 [details] ATI X300 Direct Launch I have tested 242 build manual application launch from command line with direct paths to DLLs and JARs, like it is started from NetBeans. Application succesfully runs on: - NVIDIA GeForce 7100GS (Windows XP x64) - NVIDIA GeForce GTS 250 (Windows XP x64) - NVIDIA GeForce GTS 250 (VMWare Virtual Machine with Windows XP x86) On ATI Radeon X300 test failed with strange exception about vertex_buffer_object. I think somehow OpenGL implementation has chosen GL4 profile. P.S. What if "PFID"?
PFD == Pixelformat Descriptor PFD ID .. the id of such a beast. I guess I found the culprit for these failures, related to Windows/AWT/GLCanvas. (There were other minor bugs I already fixed but commited yet in regards to the WGL Dummy Window). On X11/AWT/GLCanvas we select a matching XVisualID/FBConfigID for the given GLCapabilities, then we iterate through all AWT GraphicsConfig: - using reflection 'sun.awt.X11GraphicsConfig' to fetch the VisualID - if matching selecting this AWT GraphicsConfig. Hence we have a matching pair of native and AWT graphic config, the latter is then used to create the native peer within addNotify(). Currently on Windows this is not the case, ie. we only select a matching PFDID for the given GLCapabilities, but don't match the AWT GraphicsConfig. This worked 'by accident' if both configuration matched. However, starting with Javaws somehow lead to a different PFDID / AWT config setup. So I am in the middle of adding: - using reflection 'sun.awt.Win32GraphicsConfig' to fetch the PFDID - if matching selecting this AWT GraphicsConfig. Which is the missing part. Due to the nature of Windows PFD ID, ie that you need an HDC to query, I also have to change the current methods in the factories a bit and clean them up, ie simplify 'em since they still are too messy, long and hence error prone. I also will change the behavior in case we cannot match any native ID with the AWT ones, ie throwing an exception as a last resort. This gives us at least a meaningful 'exit' instead of just a JVM crash. As you can already see, we do rely on these sun.awt.*GraphicsConfig private implementations, which makes our AWT binding (GLCanvas) depending on them. What is worse, it makes our AWT binding specific, not generic for any AWT implementation, since we these non standard APIs. Comparing this to NEWT's AWT binding, NewtCanvasAWT, makes the NEWT one more generic to any AWT implementation, since it only relies on the JAWT specification, not any private packages/classes. I hope I will be done with this within a few hours. Thank you for finding this issue Alexander, it's a great help.
I don't know where to write about this ... I think compilation of 244 build has stuck on hudson server ...
JOGL d453a86de60cd4171373814f6cf7baf65ef1d7dc .. acda58e3d4a6fd735d0ec755a22b7ed44d02746f build #248 is on the way on hudson Tested locally (signed, applets & webstart) on X11/Win7 AMD/NVidia. Will make rc2 later today. Then please test with jogl-demos applets/webstart. One last issue I have here is: Windows 7 x64, NVIDIA 8600M GT, driver 260.99 Immediate crash with Gears applet, where the NEWT applets work. However, the following works flawless here: Kubuntu x64, NVIDIA GTX 460, 260.19.21 Windows 7 x64, AMD HD 5800, driver 10.09 Windows 7 x64, NVIDIA NVS 3100M, driver 257.38