Login  Register

Re: Jogl Using Wrong (Generic) Graphics Adapter

Posted by Sven Gothel on Nov 30, 2014; 10:12am
URL: https://forum.jogamp.org/Jogl-Using-Wrong-Generic-Graphics-Adapter-tp4033216p4033685.html

On 11/27/2014 04:09 PM, Tobi Delbruck [via jogamp] wrote:

> We are having what could be a related problem. It could be that we are doing
> something wrong.
>
> 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)

We have no unit test using the 1st _defined_ GLCapabilitiesImmutable
from the 'available' pool, as you 'chose' yours above.
Note that those instances are specialized w/ native information,
e.g. WGLGLCapabilities is being returned/used.

It simply could be, that the 1st instance triggers to create a GLContext
using the GDI driver.

The recommended way is to pass your own GLCapabilities instance when creating
an [auto]drawable, while setting your desired properties.
E.g. if you request bitmap rendering,
you might also get a GDI context on Windows.

Then the GLCapabilities chooser will pick the proper
native pixelformat and produces a chosen GLCapabilities instance.

Hope this helps a bit.

~Sven



signature.asc (828 bytes) Download Attachment