Network wide launch: analysis and solution com jogamp. opengl. GLException: J3D-Renderer-1: createImpl ARB n/a but required

Posted by nickk on Tue, 08 Feb 2022 10:11:20 +0100

  • Detailed error
com.jogamp.opengl.GLException: J3D-Renderer-1: createImpl ARB n/a but required, profile > GL2 requested (OpenGL >= 3.1). Requested: GLProfile[GL3bc/GL3bc.hw], current: 3.1 (Compat profile, compat[ES2, ES3], FBO, hardware) - 3.1 Mesa 20.0.8
	at jogamp.opengl.x11.glx.X11GLXContext.createImpl(
	at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(
	at jogamp.opengl.GLContextImpl.makeCurrent(
	at jogamp.opengl.GLContextImpl.makeCurrent(

CONTEXT_CREATION_ERROR: Renderer: Error creating Canvas3D graphics context
graphicsDevice = X11GraphicsDevice[screen=0]
canvas =[canvas0,0,0,1433x806]
X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 1/1, reusable (open, marked uncloseable): 0, pending (open in creation order): 1)
X11Util: Open X11 Display Connections: 1
X11Util: Open[0]: NamedX11Display[:0, 0x7f30d73600, refCount 1, unCloseable false]
  • Solution 1 (valid for some versions of LINUX)

com.jogamp.opengl.GLException: J3D-Renderer-1: createImpl ARB n/a but required, profile > GL2 reques_ Liu Kunpeng - CSDN blog

  • Analyze the cause: often flash back on the new LINUX system

Previously, on the old KYLIN/UOS system, the problem was indeed solved with method 1. After the new version was changed last year, this move didn't work. It collapsed and retreated directly. Originally, if the function is invalid and does not flash back, it will not be settled (because it is almost inevitable to flash back on Apple); Or everyone dies. As a result, something interesting happened: on KYLIN/UOS, the machines in Wuxi performed normally, and Tai'an often died. It is speculated that it is caused by different graphics cards. So I thought: can you analyze the operation path and see if it can be solved? At least find out why.

  • createImpl

It can be seen from the error that this is the place where the exception occurred. Naturally, you can find the bifurcation here.

Initially, the branch is generated in line 426. If (0! = contextHandle) means that the contextHandle generation fails, resulting in flash back. Why flash back? That should be related to local methods.

contextHandle = GLX.glXCreateContext()

  • createContextARB

When correct, major=3, minor=1.

  • AbstractGraphicsConfiguration

On the virtual machine, GLProfile[GL2/GL2.hw]

On the error machine, GLProfile[GL3/GL3.hw]

So where did this come from? When the Surface is generated. I want to continue tracking and see how to load it. Later, I thought that this idea was wrong. Different machines support different things, so we can't enforce unification.

  • contextHandle=0 does not make an error.

I try to forcibly return 0. There is no error on the virtual machine. There is an output message to the effect that GL3 is not supported. Fall back to GL2.

  • Reason for flash back

Since contextHandle=0 does not cause problems, this sentence has problems:

if( glp.isGL3() && createContextARBTried )

Combined with the information of Config, the judgment on the error machine is just true, enter the code, and the one pass operation will crash.

  • terms of settlement

The solution is really simple. Just prevent the above statement from being true. I defined a constant: ENABLE_GL3_TO_GL2. Everything is normal after the test.

Is it easy? The real credit is the great open source. Without them, everything is nonsense. Therefore, I will make the modification public (non disclosure violates the open source agreement).

Topics: Java