Incorrect context on GLCanvas drawable

Hi,

I have tried the program which succeeds to get the relevant OpenGL version, with -Dsun.java2d.noddraw=true AND -Dsun.java2d.noddraw=false. I got this on Win 10 + Azul JDK 8 + Intel IRIS.

sun.java2d.noddraw:true
Screen device # 0: \Display0
Screen device # 0, configuration # 0:sun.awt.Win32GraphicsConfig@1b436097[dev=Win32GraphicsDevice[screen=0],pixfmt=1]
Screen device # 0, configuration # 1:sun.awt.Win32GraphicsConfig@5e41ed9b[dev=Win32GraphicsDevice[screen=0],pixfmt=2]
Screen device # 0, configuration # 2:sun.awt.Win32GraphicsConfig@17ec3187[dev=Win32GraphicsDevice[screen=0],pixfmt=5]
Screen device # 0, configuration # 3:sun.awt.Win32GraphicsConfig@6f55953d[dev=Win32GraphicsDevice[screen=0],pixfmt=6]
Screen device # 0, configuration # 4:sun.awt.Win32GraphicsConfig@6f121798[dev=Win32GraphicsDevice[screen=0],pixfmt=9]
Screen device # 0, configuration # 5:sun.awt.Win32GraphicsConfig@3e6e12d4[dev=Win32GraphicsDevice[screen=0],pixfmt=10]
NewFrame created in thread [15], isEDT: true
* Context GL version: 4.6 (Compat profile, arb, compat[ES2, ES3, ES31], FBO, hardware) - 4.6.0 - Build 27.20.100.9664


I however tried changing JDK and got an interesting failure when using the JDK provided by Eclipse (which is a JDK 17 for me). This failure happens both with -Dsun.java2d.noddraw=true AND -Dsun.java2d.noddraw=false

Screen device # 0: \Display0
Screen device # 0, configuration # 0:sun.awt.Win32GraphicsConfig@bb422b5[dev=Win32GraphicsDevice[screen=0],pixfmt=1]
Screen device # 0, configuration # 1:sun.awt.Win32GraphicsConfig@14fbff2[dev=Win32GraphicsDevice[screen=0],pixfmt=2]
Screen device # 0, configuration # 2:sun.awt.Win32GraphicsConfig@76449731[dev=Win32GraphicsDevice[screen=0],pixfmt=5]
Screen device # 0, configuration # 3:sun.awt.Win32GraphicsConfig@7664224d[dev=Win32GraphicsDevice[screen=0],pixfmt=6]
Screen device # 0, configuration # 4:sun.awt.Win32GraphicsConfig@5c6f07be[dev=Win32GraphicsDevice[screen=0],pixfmt=9]
Screen device # 0, configuration # 5:sun.awt.Win32GraphicsConfig@20a383ee[dev=Win32GraphicsDevice[screen=0],pixfmt=10]
Exception in thread "AWT-EventQueue-0" com.jogamp.opengl.GLException: Unable to determine GraphicsConfiguration: WindowsWGLGraphicsConfiguration[DefaultGraphicsScreen[WindowsGraphicsDevice[type .windows, connection decon, unitID 0, handle 0x0, owner false, NullToolkitLock[obj 0x2ef89e1f]], idx 0], pfdID 8, ARB-Choosen true,
        requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw], on-scr[.]],
        chosen    GLCaps[wgl vid 8 arb: rgba 10/10/10/2, opaque, accum-rgba 0/0/0/0, dp/st/ms 24/8/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw], on-scr[.]]]
        at jogamp.opengl.windows.wgl.awt.WindowsAWTWGLGraphicsConfigurationFactory.chooseGraphicsConfigurationImpl(WindowsAWTWGLGraphicsConfigurationFactory.java:182)
        at com.jogamp.nativewindow.GraphicsConfigurationFactory.chooseGraphicsConfiguration(GraphicsConfigurationFactory.java:424)
        at com.jogamp.opengl.awt.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:1513)
        at com.jogamp.opengl.awt.GLCanvas.addNotify(GLCanvas.java:609)
        at java.desktop/java.awt.Container.addImpl(Container.java:1150)
        at java.desktop/java.awt.Container.add(Container.java:1001)
        at org.jzy3d.chart.JoglContextTestCase.buildScene(JoglContextTestCase.java:91)
        at org.jzy3d.chart.JoglContextTestCase.buildSceneAndCheckConfigurations(JoglContextTestCase.java:50)
        at org.jzy3d.chart.JoglContextTestCase.access$0(JoglContextTestCase.java:20)
        at org.jzy3d.chart.JoglContextTestCase$2.run(JoglContextTestCase.java:104)
        at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
        at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771)
        at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
        at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
        at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741)
        at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Do you use the latest release candidate?

Yes, 2021-01-11 RC.

Hi all.

On my side, I've run the test case with Adoptium OpenJDK 8 on many different Windows 10 PCs, with different hardware configurations (both NVIDIA adapters and AMD adapters, both desktops and notebooks), and I've been able to reproduce the issue (i.e., the OpenGL 1.1 context obtained on GLCanvas' init() callback) on all the different Windows PCs that I've tested.

I am using JOGL 2021-01-11 RC as well.

Best regards,

Marco Sambin

I have tried with Adoptium JDK 8 and haven t been able to reproduce as well.

The laptop is a Dell XPS. I will try with another windows machine.

In my humble opinion, it would be more pertinent to test with at least Adoptium OpenJDK 11 as Java 8 isn't an LTS version and anyway, I stopped using Java 8 a long time ago. Please be a lot more accurate about the hardware and keep in mind that JOGL officially does NOT support Optimus and equivalents (AMD Switchable, PowerXpress, etc), i.e JOGL doesn't support a change of GPU used by a software at runtime.

If someone can rebuild JOGL and test with this, it will be useful for me:
#ifdef _WIN32
#include <windows.h>
extern "C" __declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;
extern "C" __declspec(dllexport) DWORD AmdPowerXpressRequestHighPerformance = 0x00000001;
#endif

No luck, I still can't reproduce with my other Win10, a Dell Optiflex with an Intel IRIS GPU :/

Hi Julien,

I built for MacOS 10, 11 and Ubuntu 20 successfully, so I just started building for Win10/64bit.

I got stucked on a link error while building Gluegen, maybe you already encountered this and have a suggestion?

gluegen.build.c.impl:
     [echo] clearing gluegen.build.shasum.done (2) - was ${gluegen.build.shasum.done}
     [echo] Output lib name = gluegen_rt -> gluegen_rt.dll [shared]
     [echo] Compiling src/native/windows/*.c src/native/common/*.c
     [echo] user.dir=C:\Users\Martin\Dev\jzy3d\external\jogamp\gluegen\make
       [cc] Starting dependency analysis for 7 files.
       [cc] 7 files are up to date.
       [cc] 0 files to be recompiled from dependency analysis.
       [cc] 0 total files to be compiled.
       [cc] Starting link
       [cc] C:/Mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/bin/ld.exe: unrecognised emulation mode: i386pep
       [cc] Supported emulations: i386pe
       [cc] collect2.exe: error: ld returned 1 exit status

The full build output is here.

By the way, where should we add the C code you mention?

Cheers

Are you sure that your whole tool chain and your compiler support the 64-bit architecture?
https://stackoverflow.com/questions/58791448/unrecognised-emulation-mode-i386pep-when-linking-x64-asm-on-windows-10

I'll indicate where to put the few lines I mentioned when I have some time to look for the most appropriate location.

Thanks for the link. The last comment helped : "Just realized MinGW-W64 does have an option to specify x86_64 architecture during installation process. Not sure why i686 is selected by default."

Now the build succeeds.

I can add that JOGL unit test all passed with 2.4 on Windows 10 + JDK 11. It needed 49 minutes to run.

Hi guys.
Following to your input, I tried my test case with Adoptium OpenJDK 11, and I can reproduce exactly the same (incorrect) behavior with my test case.

Here are the details of the test on my machine (I can provide details of other machines where I can reproduce exactly the same behavior as well):

HP Z640 Workstation
Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz   2.20 GHz
NVIDIA GeForce GTX 1060 6GB (Driver version: 456.71)
32 GB RAM
Windows 10 Pro for Workstations, 64-bit

Launching this command:

"C:\Program Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot\bin\java.exe" -cp .\jars\MyApp.jar;.\jars\jogl-all.jar;.\jars\gluegen-rt.jar;.\jars\jogl-all-natives-windows-amd64.jar;.\jars\gluegen-rt-natives-windows-amd64.jar -Dsun.java2d.noddraw=true vtk.sample.rendering.JoglContextTestCase

I get the following (faulty) output:

Screen device # 0: \Display0
Screen device # 0, configuration # 0:
Screen device # 0, configuration # 1:
Screen device # 0, configuration # 2:
Screen device # 0, configuration # 3:
Screen device # 0, configuration # 4:
Screen device # 0, configuration # 5:
Screen device # 1: \Display1
Screen device # 1, configuration # 0:
Screen device # 1, configuration # 1:
Screen device # 1, configuration # 2:
Screen device # 1, configuration # 3:
Screen device # 1, configuration # 4:
Screen device # 1, configuration # 5:
NewFrame created in thread [17], isEDT: true
* Context GL version: 1.1 (Compat profile, arb, compat[], FBO, hardware) - 1.1.0

On the other side, launching the following command:

"C:\Program Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot\bin\java.exe" -cp .\jars\MyApp.jar;.\jars\jogl-all.jar;.\jars\gluegen-rt.jar;.\jars\jogl-all-natives-windows-amd64.jar;.\jars\gluegen-rt-natives-windows-amd64.jar vtk.sample.rendering.JoglContextTestCase

I get the following (correct) output:

Screen device # 0: \Display0
Screen device # 0, configuration # 0:
Screen device # 1: \Display1
Screen device # 1, configuration # 0:
NewFrame created in thread [17], isEDT: true
* Context GL version: 4.6 (Compat profile, arb, compat[ES2, ES3, ES31, ES32], FBO, hardware) - 4.6.0 NVIDIA 456.71

I can do other tests if it may be useful.
Regards,

Marco Sambin

Hi,

There is another discussion here with a user having an incorrect GL 1.1 version on a computer supposed to support GL3. It is Win10, Intel HD graphics, Java 8. Julien indicated an existing bug due to a limitation on Intel. I know you are on NVidia and probably already red this, but that may give ideas...

Hi, and thanks for your interest in this issue.

Actually, I don't think it's something specific to the configuration of my PC.
Here is another Windows 10 PC where I can reproduce exactly the same faulty behavior with my test case:

HP Z2 Mini G4 Workstation
Intel(R) Xeon(R) E-2174G CPU @ 3.80GHz   3.79 GHz
RAM 32 GB
NVIDIA Quadro P1000 - Driver version 411.95
Windows 10 Pro for Workstations - 64-bit

C:\Users\admin\Desktop\JOGLTestCase>"C:\Program Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot\bin\java.exe" -cp .\classes;.\jars\jogl-all.jar;.\jars\gluegen-rt.jar;.\jars\jogl-all-natives-windows-amd64.jar;.\jars\gluegen-rt-natives-windows-amd64.jar -Dsun.java2d.noddraw=true vtk.sample.rendering.JoglContextTestCase
Screen device # 0: \Display0
Screen device # 0, configuration # 0:
Screen device # 0, configuration # 1:
Screen device # 0, configuration # 2:
Screen device # 0, configuration # 3:
Screen device # 0, configuration # 4:
Screen device # 0, configuration # 5:
Screen device # 1: \Display1
Screen device # 1, configuration # 0:
Screen device # 1, configuration # 1:
Screen device # 1, configuration # 2:
Screen device # 1, configuration # 3:
Screen device # 1, configuration # 4:
Screen device # 1, configuration # 5:
NewFrame created in thread [17], isEDT: true
* Context GL version: 1.1 (Compat profile, arb, compat[], FBO, hardware) - 1.1.0


C:\Users\admin\Desktop\JOGLTestCase>"C:\Program Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot\bin\java.exe" -cp .\classes;.\jars\jogl-all.jar;.\jars\gluegen-rt.jar;.\jars\jogl-all-natives-windows-amd64.jar;.\jars\gluegen-rt-natives-windows-amd64.jar vtk.sample.rendering.JoglContextTestCase
Screen device # 0: \Display0
Screen device # 0, configuration # 0:
Screen device # 1: \Display1
Screen device # 1, configuration # 0:
NewFrame created in thread [17], isEDT: true
* Context GL version: 4.6 (Compat profile, arb, compat[ES2, ES3, ES31, ES32], FBO, hardware) - 4.6.0 NVIDIA 411.95


Hope it helps.
I have other different machines where I can reproduce the issue, if necessary.

Regards,

Marco

Hi all,

this is yet another PC configuration where I can reproduce the issue with my test case:

HP Elite 7500 Series MT
Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz   3.40 GHz
RAM 16 GB
GeForce GT 640 - Driver version: 388.73
Windows 10 Pro - 64-bit


C:\Users\Marco\Desktop\JOGLTestCase>"C:\Program Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot\bin\java.exe" -cp .\classes;.\jars\jogl-all.jar;.\jars\gluegen-rt.jar;.\jars\jogl-all-natives-windows-amd64.jar;.\jars\gluegen-rt-natives-windows-amd64.jar -Dsun.java2d.noddraw=true vtk.sample.rendering.JoglContextTestCase
Screen device # 0: \Display0
Screen device # 0, configuration # 0:
Screen device # 0, configuration # 1:
Screen device # 0, configuration # 2:
Screen device # 0, configuration # 3:
Screen device # 0, configuration # 4:
Screen device # 0, configuration # 5:
NewFrame created in thread [17], isEDT: true
* Context GL version: 1.1 (Compat profile, arb, compat[], FBO, hardware) - 1.1.0


C:\Users\Marco\Desktop\JOGLTestCase>"C:\Program Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot\bin\java.exe" -cp .\classes;.\jars\jogl-all.jar;.\jars\gluegen-rt.jar;.\jars\jogl-all-natives-windows-amd64.jar;.\jars\gluegen-rt-natives-windows-amd64.jar vtk.sample.rendering.JoglContextTestCase
Screen device # 0: \Display0
Screen device # 0, configuration # 0:
NewFrame created in thread [17], isEDT: true
* Context GL version: 4.6 (Compat profile, arb, compat[ES2, ES3, ES31, ES32], FBO, hardware) - 4.6.0 NVIDIA 388.73


Basically, it happens on ALL the Windows PCs I've tested so far.

Regards,

Marco Sambin

Hi,

Here are the two configurations that work for me :

Windows 10
Dell XPS laptop
Intel Core i5-1135G7 @ 2.40GHz × 8 (11th Gen)
Mesa Intel® Iris Xe Graphics (TGL GT2)
13' screen (HiDPI)

Windows 10
Dell OptiFlex
Intel Core i5-1145G7 @ 2.60GHz × 8 (11th Gen)
Mesa Intel® Iris Xe Graphics (TGL GT2)
22' Dell screen, low res (No HiDPI)

Do you have configs with the same GPU than mine?

Note that when I way "working" it just means I have a correct OpenGL version detected (4.6). When using this "working" version on HiDPI screen, I still face the unresolved scaling issue mentionned here.

TLDR : what's the outcome on your side with -Dsun.java2d.noddraw=true  -Dsun.java2d.opengl=True ?

I continued to reproduce your issue with "random" changed.

I first tried to compare the list of GraphicsConfiguration with the single one referenced by GLCanvas and was surprised by two things : (1) all configurations in the list are exactly similar (2) all of them even the one held by GLCanvas had hardware acceleration turned off.

I then tried enabling hardware acceleration from Windows settings and activated/desactivated it for javaw.exe. Hardware acceleration was still always off.

(tried updating drivers but they were up to date)

I then tried playing with -Dsun.java2d.opengl=True (or true for no console feedback):

- When -Dsun.java2d.noddraw=false  -Dsun.java2d.opengl=True : single configuration in the list with activated acceleration, GLCanvas has disabled acceleration, GL Version 4.6
- When -Dsun.java2d.noddraw=true  -Dsun.java2d.opengl=True : single configuration in the list with activated acceleration, GLCanvas has disabled acceleration, GL Version 4.6
- When -Dsun.java2d.noddraw=true -Dsun.java2d.opengl=false :  6 configurations in the list with disabled acceleration, GLCanvas has disabled acceleration, GL Version 4.6

So I still can't reproduce your issue, neither activate acceleration for my GLCanvas BUT without understanding why, -Dsun.java2d.noddraw=true  -Dsun.java2d.opengl=True won't lead to a multi-configuration so MAYBE that may have an impact on your side.

Console output in this case with this updated version of the test : JoglContextTestCase.java

sun.java2d.opengl:true
sun.java2d.noddraw:true
--------------------
Default graphics configuration
        ColorModel   : DirectColorModel: rmask=ff0000 gmask=ff00 bmask=ff amask=0
        Img Caps     : accelerated: true volatile: true
        Bounds       : java.awt.Rectangle[x=0,y=0,width=1920,height=1080]
        Translucency : true
        Buffer caps / Back       : accelerated: true volatile: true
        Buffer caps / Front      : accelerated: true volatile: true
        Buffer caps / FullScreen : false
--------------------
Screen device # 0: \Display0
 Screen device # 0, configuration # 0:
        ColorModel   : DirectColorModel: rmask=ff0000 gmask=ff00 bmask=ff amask=0
        Img Caps     : accelerated: true volatile: true
        Bounds       : java.awt.Rectangle[x=0,y=0,width=1920,height=1080]
        Translucency : true
        Buffer caps / Back       : accelerated: true volatile: true
        Buffer caps / Front      : accelerated: true volatile: true
        Buffer caps / FullScreen : false
----
NewFrame created in thread [15], isEDT: true
* Context GL version: 4.6 (Compat profile, arb, compat[ES2, ES3, ES31], FBO, hardware) - 4.6.0 - Build 27.20.100.9664
        ColorModel   : DirectColorModel: rmask=ff0000 gmask=ff00 bmask=ff amask=0
        Img Caps     : accelerated: false volatile: false
        Bounds       : java.awt.Rectangle[x=0,y=0,width=1920,height=1080]
        Translucency : true
        Buffer caps / Back       : accelerated: false volatile: false
        Buffer caps / Front      : accelerated: false volatile: false
        Buffer caps / FullScreen : false

I got confirmation from a collaborator having windows+Nvidia adapters that the erroneous GL version on windows with noddraw=true is fixed by adding opengl=true.

Also : removing the noddraw option avoid the erroneous GL version problem.

Hi Martin,

thank you for your feedback, I appreciate.

Well, I confirm that an OpenGL 4.6 context is returned both in the case the noddraw system property is NOT passed, and in the case opengl=true is passed. This happens because, for some reason, in both cases just a single GraphicsConfiguration is returned for each GraphicsDevice.

On the other side, with noddraw=true, 6 GraphicsConfiguration are returned for each GraphicsDevice, and this seems to be the actual source of problems for the GLContext of my GLCanvas. BTW, these 6 GraphicsConfiguration are "similar" but not identical, as they only differ for their "pixel format" attribute.

Unfortunately, both workarounds (1. avoiding passing noddraw=true, 2. passing opengl=true) are NOT viable solutions for me.

In fact:

1) If I don't pass noddraw=true, I have rendering issues both with JOGL and within the rest of my application.

2) If I pass opengl=true, with many graphics adapters' device drivers I have Swing rendering artifacts and issues within my application. E.g., incorrect painting of toolbar buttons, etc.

So, I need to return to my initial question: why in the case 6 GraphicsConfigurations are returned, and getConfigurations() is called, then GLCanvas is initialized with an Open GL 1.1 context (at least with all NVIDIA adapters)? Is this something which can be corrected in JOGL?

I am looking forward to hearing from you.
Thanks and best regards,

Marco Sambin