OpenGL issue

OK, working on getting vtk9.5 (custom build) to work on my M series mac, and running into failures when running. Have narrowed it down to vktOpenGLState failing when calling lines like this:

::glGetFloatv(GL_DEPTH_CLEAR_VALUE, &fparams);

As in the past with previous versions, I’ve been using the 2.4.0-rc4 version of the openGL/glugen jars, and my build script hasn’t changed. Any thoughts on what is going on here?

In addition - it looks like the WebGPU/Dawn path is how I can attempt to use Metal vs OpenGL?

Hello @Gilthalas

Any context around those lines of code like a call stack could help us narrow it down.

Are you using the Java wrappings?

As of VTK 9.5, support for rendering on macOS desktop using webgpu was not implemented. It might be added in 9.6 as an experimental feature.

Ugh. That is unfortunate about macOS support in vtk9.5 - everything I read in documentation seemed to indicate otherwise. If that ends up getting enabled in a future release, I am more than happy to help test.

I am using the Java bindings, yes. We have been building like this for years. When it tries to initialize the render, I get a hard core dump.

Stack: [0x000000032dd74000,0x000000032df77000],  sp=0x000000032df74a20,  free space=2050k
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  vtk.vtkGenericOpenGLRenderWindow.OpenGLInit_43()V+0
j  vtk.vtkGenericOpenGLRenderWindow.OpenGLInit()V+1
j  vtk.rendering.jogl.vtkAbstractJoglComponent$1.init(Lcom/jogamp/opengl/GLAutoDrawable;)V+97
j  jogamp.opengl.GLDrawableHelper.reshape(Lcom/jogamp/opengl/GLAutoDrawable;IIII)V+63
j  com.jogamp.opengl.awt.GLJPanel$Updater.display(Lcom/jogamp/opengl/GLAutoDrawable;)V+177
j  com.jogamp.opengl.awt.GLJPanel$10.run()V+11
j  jogamp.opengl.GLDrawableHelper.invokeGLImpl(Lcom/jogamp/opengl/GLDrawable;Lcom/jogamp/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+203
j  jogamp.opengl.GLDrawableHelper.invokeGL(Lcom/jogamp/opengl/GLDrawable;Lcom/jogamp/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+72
j  com.jogamp.opengl.awt.GLJPanel$OffscreenBackend.doPaintComponent(Ljava/awt/Graphics;)V+29
j  com.jogamp.opengl.awt.GLJPanel.paintComponent(Ljava/awt/Graphics;)V+224
j  javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+286 java.desktop@17.0.9
j  javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+523 java.desktop@17.0.9
j  javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+318 java.desktop@17.0.9
j  javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+523 java.desktop@17.0.9
j  javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+318 java.desktop@17.0.9
j  javax.swing.JLayeredPane.paint(Ljava/awt/Graphics;)V+73 java.desktop@17.0.9
j  javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+523 java.desktop@17.0.9
j  javax.swing.JComponent.paintToOffscreen(Ljava/awt/Graphics;IIIIII)V+72 java.desktop@17.0.9
j  javax.swing.RepaintManager$PaintManager.paintDoubleBufferedImpl(Ljavax/swing/JComponent;Ljava/awt/Image;Ljava/awt/Graphics;IIII)V+163 java.desktop@17.0.9
j  javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Ljavax/swing/JComponent;Ljava/awt/Image;Ljava/awt/Graphics;IIII)V+46 java.desktop@17.0.9
j  javax.swing.RepaintManager$PaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)Z+128 java.desktop@17.0.9
j  javax.swing.RepaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)V+52 java.desktop@17.0.9
j  javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+221 java.desktop@17.0.9
j  java.awt.GraphicsCallback$PaintCallback.run(Ljava/awt/Component;Ljava/awt/Graphics;)V+2 java.desktop@17.0.9
j  sun.awt.SunGraphicsCallback.runOneComponent(Ljava/awt/Component;Ljava/awt/Rectangle;Ljava/awt/Graphics;Ljava/awt/Shape;I)V+130 java.desktop@17.0.9
j  sun.awt.SunGraphicsCallback.runComponents([Ljava/awt/Component;Ljava/awt/Graphics;I)V+157 java.desktop@17.0.9
j  java.awt.Container.paint(Ljava/awt/Graphics;)V+58 java.desktop@17.0.9
j  java.awt.Window.paint(Ljava/awt/Graphics;)V+68 java.desktop@17.0.9

I’ve narrowed it down (by going into the C code, commenting out, rebuilding) to it failing when trying to invoke vtkOpenGLState -> Reset(), and in particular when in that function when it tries to call functions similar to the one I mentioned before (::glGetFloatv(GL_DEPTH_CLEAR_VALUE, &fparams);

Let me know if there is anything else I can provide. Looking forward to being able to upgrade to vtk9.5. Thanks.

Our application also uses VTK 9.5 on MacOS. What I would be interested in knowing is what version of MacOS are you using and what version of Xcode are you using to compile everything.

For those interested, it looks like this fix by Sven fixes this problem:

https://gitlab.kitware.com/vtk/vtk/-/commit/f770c88dad74eaa2a5ac69fd5c7eb7c8d710e539

I am at least able to build master now (this change was done after 9.5.2 was released) and the test code (JoglConeRendering) works now as expected without the segfault. I’m getting ready to test it against our main application, but it seems to work so far. I also updated to use the latest JOGL 2.6 versions. I discovered this was ready for prime time thanks to https://gitlab.kitware.com/vtk/vtk/-/blob/master/Documentation/release/dev/improve-jogl-integration.md

And @Michael_Jackson - I am on macOS 15.7.1, and I’m using Xcode 16 with a custom build script using cmake to build everything. One of these days I will submit my script for people to check out…