Created attachment 666 [details] NVIDIA system information We have a Swing-based application that sometimes has this problem of dropping back to 1.1 software rendering (is this GDI?). The problem occurs when more than one GLCanvas is created, which runs in a different thread and possibly different OpenGL context. I am not too clear on OpenGL contexts, profiles, capabilities etc so we could easily be doing something wrong. But this is a problem that did not occur in the past and only started after we went to JOGL 2.x; it did not occur when we were using JOGL 1.1.1. In our headless main method, we now create a dummy window and then in each slave we assign this shared context to the new GLCanvas. But still, after a random number of new windows are opened (which is machine dependent) we get the exception occurring. Here are some details: Test machine: Windows 7x64 SP1, Nvidia GeForce GT630, Driver 344.75, 64-bit JDK 8.01, JOGL 2.2.4 Our headless, no graphics main method: public static GLAutoDrawable sharedDrawable; // This is JAERViewer.sharedDrawable final GLCapabilities caps = new GLCapabilities(GLProfile.getDefault()) ; final GLProfile glp = caps.getGLProfile(); final boolean createNewDevice = true; // use 'own' display device! sharedDrawable = GLDrawableFactory.getFactory(glp).createDummyAutoDrawable(null, createNewDevice, caps, null); sharedDrawable.display(); // triggers GLContext object creation and native realization. sharedDrawable is a static variable that can be used by all AEViewers and file preview dialogs Slave method constructor: List<GLCapabilitiesImmutable> capsAvailable=GLDrawableFactory.getDesktopFactory().getAvailableCapabilities(null); GLCapabilitiesImmutable chosenGLCaps=null; int listnum=0; for(GLCapabilitiesImmutable cap:capsAvailable){ log.info("GLCapabilitiesImmutable #"+listnum+" is "+cap.toString()); if(chosenGLCaps==null) chosenGLCaps=cap; if(listnum++>=0) break; } drawable = new GLCanvas(chosenGLCaps); drawable.setSharedAutoDrawable(JAERViewer.sharedDrawable); // TODO tobi added to try to use shared context between all viewers and file open dialog previews. No exception on construction is ever thrown. But on first instantiation of slave window display() method, we sometimes, on some machines, get this uncaught exception: WARNING: AWT-EventQueue-0 javax.media.opengl.GLException: AWT-EventQueue-0: WindowsWGLContex.createContextImpl ctx !ARB but ARB is used, profile > GL2 requested (OpenGL >= 3.0.1). Requested: GLProfile[GL4bc/GL4bc.hw], current: 1.1 (Compat profile, hardware) - 1.1.0 at jogamp.opengl.windows.wgl.WindowsWGLContext.createImpl(WindowsWGLContext.java:371) at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:694) at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:589) at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:539) at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1263) at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1131) at javax.media.opengl.awt.GLCanvas$11.run(GLCanvas.java:1394) at javax.media.opengl.Threading.invoke(Threading.java:223) at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:525) at javax.media.opengl.awt.GLCanvas.paint(GLCanvas.java:579) at sun.awt.RepaintArea.paintComponent(RepaintArea.java:264) at sun.awt.RepaintArea.paint(RepaintArea.java:240) at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:347) at java.awt.Component.dispatchEventImpl(Component.java:4959) at java.awt.Component.dispatchEvent(Component.java:4705) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:746) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86) at java.awt.EventQueue$4.run(EventQueue.java:719) at java.awt.EventQueue$4.run(EventQueue.java:717) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) After this it is not possible to create any new GLCanvas without this exception being thrown.
Created attachment 667 [details] C:\Users\tobi\Downloads\jogamp-all-platforms>etc\test.bat
My initial report was from a different machine, with same bug. The current machine I'm using is a laptop with NVIDIA NVS 520M adaptor (driver is set to use Nvidia graphics for Java applications and I confirmed this from the tray icon widget). It is difficult for me to produce small test case, I'm sorry. One symptom is that if our application creates multiple GLCanvas without rendering any of them, then the bug is not seen. It only seems to occur when a new GLCanvas is constructed after one or more already have been displayed already.
I may have chosen the wrong product (JOGL). Not sure if it should be "general-core".
To reproduce this bug is not simple, but here are steps Check out working SVN copy of jAER from https://svn.code.sf.net/p/jaer/code/jAER/trunk Run jAER from launcher script appropriate for installed OS and Java version from folder <working copy folder>\jAER\trunk Launcher: one of following (note root folder is working copy folder) C:\Users\tobi\Documents\~jaer\jAER\trunk\jaer1.5_win_jre_x64.exe4j C:\Users\tobi\Documents\~jaer\jAER\trunk\jaer1.5_win_jre_x86.exe4j C:\Users\tobi\Documents\~jaer\jAER\trunk\jAERViewer1.5_linux.sh C:\Users\tobi\Documents\~jaer\jAER\trunk\jAERViewer1.5_win32.exe C:\Users\tobi\Documents\~jaer\jAER\trunk\jAERViewer1.5_win64.exe Once AEViewer window is active, make a new window active with File/New Viewer (or ctl-n). On affected machines, this (sometimes) immediately throws up an Uncaught Exception window.
Created attachment 668 [details] jAER debug log with -Dnewt.debug=all -Dnativewindow.debug=all -Djogl.debug=all ran jAER with JOGL and native windows debug options turned on, and then opened a new AEViewer window. This is the resulting console logging output.
Created attachment 669 [details] A Log file of same problem with different application and ATI graphics This log has -Djogl.debug=all -Dnativewindow.debug.GrapicsConfiguration=true. I believe the setPixelFormat (post): hdc 0xffffffffa9010913, 32 -> 2, set: false is the root cause which later causes same tx !ARB but ARB is used, profile > GL2 requested (OpenGL >= 3.0.1). Requested: GLProfile[GL4bc/GL4bc.hw], current: 1.1 (Compat profile, hardware) - 1.1.0 error.
As an addendum to follow up post Dec 3 (http://forum.jogamp.org/Jogl-Using-Wrong-Generic-Graphics-Adapter-td4033216i20.html#a4033699), here is the log output using this GLCanvas initialization code: GLCapabilities caps=new GLCapabilities(GLProfile.getDefault()); caps.setDoubleBuffered(true); caps.setHardwareAccelerated(true); caps.setRedBits(8); caps.setGreenBits(8); caps.setBlueBits(8); caps.setAlphaBits(8); caps.setOnscreen(true); drawable = new GLCanvas(caps); The logging output with JOGL logging turned on is attached.
Created attachment 670 [details] log output using recommended capabilities procedure
Finally some progress, not in making a JUnit test case but in solving the problem. First, the problem of dropping back to software rendering was solved by replacing the call to retrieve the screen insets by the following: Dimension sd = Toolkit.getDefaultToolkit().getScreenSize(); // determine the height of the windows taskbar by this roundabout proceedure // TODO tobi removed this because it was causing a runtime native code exception using NVIDIA 181.22 driver with win xp // replaced by hardcoded lowerInset lowerInset = 64; Rectangle windowBounds = GraphicsEnvironment.getLocalGraphicsEnvironment().getMaximumWindowBounds(); if (windowBounds != null) { lowerInset = sd.height - windowBounds.height; } Secondly, I finally realized that I was doing what should not be done but is hard to catch: Running Swing/AWT code outside the Swing thread. I replaced the WindowSaver code that actually resizes the window with a call to Swing.invokeLater(): final boolean resize2 = resize; final int w2=w, h2=h, x2=x, y2=y; SwingUtilities.invokeLater(new Runnable() { public void run() { frame.setLocation(x2, y2); if (resize2 && !(frame instanceof DontResize)) { frame.setSize(new Dimension(w2, h2)); } // log.info("loaded settings location for "+frame.getName()); framemap.put(name, frame); frame.validate(); } }); Now I don't have the problems anymore. However the root of the original problem, which was caused by the call to // GraphicsConfiguration[] gc = gd.getConfigurations(); remains mysterious. I'll see how this works on various machines and report back if anything new comes up. Tobi
Handling the Windows bitmap and '!ARB GL >= 3.1' failure within bug 1150. This solves the 'followup' issue of this bug, however, we cannot deal w/ complicated Swing native surface issues. I close this bug as 'duplicate'. If the upcoming fix for Bug 1150 is not satisfactory please re-open and elaborate. *** This bug has been marked as a duplicate of bug 1150 ***