Bug 1105 - 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
Summary: javax.media.opengl.GLException: AWT-EventQueue-0: WindowsWGLContex.createCont...
Status: RESOLVED DUPLICATE of bug 1150
Alias: None
Product: Jogl
Classification: JogAmp
Component: opengl (show other bugs)
Version: 2
Hardware: All all
: --- enhancement
Assignee: Sven Gothel
Depends on: 1150
  Show dependency treegraph
Reported: 2014-12-01 14:18 CET by Tobi Delbruck
Modified: 2015-03-26 14:53 CET (History)
1 user (show)

See Also:
Type: ---
SCM Refs:
Workaround: ---

NVIDIA system information (4.28 KB, text/plain)
2014-12-01 14:18 CET, Tobi Delbruck
C:\Users\tobi\Downloads\jogamp-all-platforms>etc\test.bat (24.36 KB, text/plain)
2014-12-01 14:20 CET, Tobi Delbruck
jAER debug log with -Dnewt.debug=all -Dnativewindow.debug=all -Djogl.debug=all (1.00 MB, text/plain)
2014-12-01 19:09 CET, Tobi Delbruck
A Log file of same problem with different application and ATI graphics (354.83 KB, application/octet-stream)
2014-12-01 21:42 CET, Steve
log output using recommended capabilities procedure (572.48 KB, text/plain)
2014-12-03 14:48 CET, Tobi Delbruck

Note You need to log in before you can comment on or make changes to this bug.
Description Tobi Delbruck 2014-12-01 14:18:14 CET
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.
Comment 1 Tobi Delbruck 2014-12-01 14:20:01 CET
Created attachment 667 [details]
Comment 2 Tobi Delbruck 2014-12-01 14:23:51 CET
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.
Comment 3 Tobi Delbruck 2014-12-01 14:26:26 CET
I may have chosen the wrong product (JOGL). Not sure if it should be "general-core".
Comment 4 Tobi Delbruck 2014-12-01 14:33:16 CET
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)


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.
Comment 5 Tobi Delbruck 2014-12-01 19:09:04 CET
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.
Comment 6 Steve 2014-12-01 21:42:12 CET
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.
Comment 7 Tobi Delbruck 2014-12-03 14:47:33 CET
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());
                drawable = new GLCanvas(caps); 

The logging output with JOGL logging turned on is attached.
Comment 8 Tobi Delbruck 2014-12-03 14:48:23 CET
Created attachment 670 [details]
log output using recommended capabilities procedure
Comment 9 Tobi Delbruck 2014-12-22 12:59:29 CET
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);

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.
Comment 10 Sven Gothel 2015-03-26 14:53:06 CET
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 ***