“WARNING: Illegal reflective access by processing.opengl.PSurfaceJOGL” on getContextCapabilities()

[benfry]

This is not the same as #22, which is another WARNING: Illegal reflective access message.

Due to the workaround for processing/processing#4104, we've got a reflection hack that spews a big warning.

The hack involves getting the name of the hardware so that we can add a workaround for Intel HD Graphics 3000 devices.

Not sure if we're free to nix the hack for 4.x (though it only recently went into 3.x), or perhaps there's another way to get hardware information.

[neilcsmith-net]

If all you want to do is nix the warning, then passing some --add-opens should do it.

[sampottinger]

Hey! Started poking around to see what we can do without ‘sun.java2d’. It looks hard generally speaking without JNA to migrate out. However, the JavaCL folks might have it sorted. Seems a bit excessive to include JavaCL for that but maybe could help point us in the right direction even if we don’t use the full lib. I’ll play with it a bit. All that said, not sure if knowing the graphics card is helpful anywhere else...

[benfry]

Yeah, this is a messy one because it’s old hardware (meaning that it gets less relevant as that equipment is replaced) but it was used on a lot of apple machines, so there’s a large (or at least very vocal) installed base.

Is there a JNA approach? I’d be more inclined to move that into core than OpenCL, since it’d be useful elsewhere (hidpi detection, display resolutions, menubar hacks, etc...)

[sampottinger]

Yeah it looks possible with JNA. I’ll look into it:

• https://github.com/java-native-access/jna/blob/master/contrib/platform/src/com/sun/jna/platform/mac/IOKit.java
• http://sharmar0hit.blogspot.com/2013/08/detecting-graphics-hardware-using.html?m=1

[neilcsmith-net]

@sampottinger doesn't JOGL already have an API that gives you this information?! As does LWJGL.

Still think you'll have fun trying to remove all warnings right now - and most of those are probably as safe to use for now as they ever were - ie. not! 😄

[sampottinger]

Thanks @neilcsmith-net! I looked into JOGL (GLProfile) and it wasn't clear to me that this information was accessible. Do you have the API reference for JOGL or LWJGL that you had in mind? Thanks!

[neilcsmith-net]

@sampottinger well, isn't the same information available in PGraphicsOpenGL at https://github.com/processing/processing4/blob/master/core/src/processing/opengl/PGraphicsOpenGL.java#L6884 This is set using the OpenGL API (JOGL or LWJGL). It's a little later checking, but early enough I think? It's where the Pi workarounds are.

[sampottinger]

Sorry I dropped the thread on this one... Anyway, thank you @neilcsmith-net!

Yeah I can find what I'm looking for pretty easily if I have the GL context already active. For the folks following along at home, consider this sketch:

import com.jogamp.opengl.*;

void setup() {
  size(100, 100, P3D);
  GL gl = GLContext.getCurrentGL(); 
  println(gl.glGetString(GL.GL_VENDOR));
  println(gl.glGetString(GL.GL_RENDERER));
}

void draw() {}

That said, inside Processing, this is happening up at initDisplay inside PSurfaceJOGL which I think was intended to happen before initGL. Now that I am taking a closer look though, I'm not sure if there is a reason fboAllowed has to be part of initDisplay. I'll move it and we should (?) be good to go.

[sampottinger]

Blocked on #73.

[sampottinger]

Posted possible solution at #76! :D

[benfry]

Should be fixed in cc39c94

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.