Recommended way of loading OpenGL functions in GTK4 apps?

I have a Rust GTK4 app (using the latest gtk4 crate) that renders on a GLArea using OpenGL.

Currently I’m calling OpenGL functions via epoxy, which is a bindings crate for libepoxy.

I don’t remember how I came up with this approach and I’m wondering if this is the recommended way of using OpenGL in GTK4 applications to draw stuff on a GtkGLArea.

I think GTK4 renders its own widgets using OpenGL (correct me if I’m wrong), so it should be loading OpenGL functions. Can I not use the same ones that it’s already loading?

The reason why I ask is, this app works fine on Linux (OpenGL 3.2), but segfaults in a libepoxy call on macOS 12 (OpenGL 4.1). I’m wondering if this is libepoxy related, or maybe because of a bad interaction between GTK and libepoxy. The app does a few GL calls before segfault (glGetError returns 0 after every call) and then segfaults in glViewport in libepoxy.

GTK uses libepoxy to load the GL library and call its symbols. In C, you’d use libepoxy automatically by virtue of using GTK.

Thanks. Does that mean I’m using the right GL functions that GTK is also using, and the problem is not some kind of incompatibility between GTK’s GL functions and my apps?

It could entirely be an issue of the macOS backend in GDK; I would recommend creating a small, self-contained example that exhibits the same crash in C, and then opening an issue on the GTK issue tracker.

I created a minimal repro in GitHub - osa1/gtk_segfault_repro.

cargo run on Linux works fine. On macOS 12 it segfaults.

On Linux it tries to load libepoxy.so.0. On macOS it tries to load libepoxy.0.dylib.

Are you able to see the same problem when running this example from gtk4-rs? gtk4-rs/examples/glium_gl_area at master · gtk-rs/gtk4-rs · GitHub

That example also segfaults. Backtrace:

  * frame #0: 0x0000000000000000
    frame #1: 0x0000000100196774 glium_gl_area`epoxy::GetString::h6d22e03d9d8fa549(name=7938) at bindings.rs:5804:17
    frame #2: 0x0000000100232bc0 glium_gl_area`glium::gl::Gl::GetString::h6ef051b8117da751(self=0x000000016fde7a70, name=7938) at gl_bindings.rs:7033:102
    frame #3: 0x00000001001f6238 glium_gl_area`glium::version::get_gl_version::ha53c6d42a8e51e9a(gl=0x000000016fde7a70) at version.rs:43:19
    frame #4: 0x0000000100024294 glium_gl_area`glium::context::Context::new::heaa90dc741799490(backend=GliumGLArea @ 0x000000016fde7a68, check_current_context=true, callback_behavior=DebugCallbackBehavior @ 0x000000016fdfd530) at mod.rs:170:23
    frame #5: 0x000000010001e5c4 glium_gl_area`_$LT$glium_gl_area..glium_gl_area..imp..GliumGLArea$u20$as$u20$gtk4..subclass..widget..WidgetImpl$GT$::realize::h1417328ca3003ce3(self=0x0000000103080400) at imp.rs:161:22
    frame #6: 0x0000000100001760 glium_gl_area`gtk4::subclass::widget::widget_realize::h36da5db9dd43fb03(ptr=0x0000000103080cb0) at widget.rs:785:5
    frame #7: 0x0000000100bdec08 libgobject-2.0.0.dylib`_g_closure_invoke_va + 216
    frame #8: 0x0000000100bf4480 libgobject-2.0.0.dylib`g_signal_emit_valist + 868
    frame #9: 0x0000000100bf4ce4 libgobject-2.0.0.dylib`g_signal_emit + 28
    frame #10: 0x000000010167694c libgtk-4.1.dylib`gtk_widget_realize + 220
    frame #11: 0x00000001016767dc libgtk-4.1.dylib`gtk_widget_map + 92
    frame #12: 0x00000001016838c8 libgtk-4.1.dylib`gtk_widget_real_map + 96
    frame #13: 0x000000010168cb54 libgtk-4.1.dylib`gtk_window_map + 52
    frame #14: 0x0000000100bdec08 libgobject-2.0.0.dylib`_g_closure_invoke_va + 216
    frame #15: 0x0000000100bf4480 libgobject-2.0.0.dylib`g_signal_emit_valist + 868
    frame #16: 0x0000000100bf4ce4 libgobject-2.0.0.dylib`g_signal_emit + 28
    frame #17: 0x00000001016767f0 libgtk-4.1.dylib`gtk_widget_map + 112
    frame #18: 0x000000010168cae8 libgtk-4.1.dylib`gtk_window_show + 72
    frame #19: 0x0000000100bdec08 libgobject-2.0.0.dylib`_g_closure_invoke_va + 216
    frame #20: 0x0000000100bf4480 libgobject-2.0.0.dylib`g_signal_emit_valist + 868
    frame #21: 0x0000000100bf4ce4 libgobject-2.0.0.dylib`g_signal_emit + 28
    frame #22: 0x000000010167648c libgtk-4.1.dylib`gtk_widget_show + 172
...

I reported this in gtk-rs issue tracker: glium_gl_area example segfaults on macOS 12 · Issue #1209 · gtk-rs/gtk4-rs · GitHub

Installing libepoxy from source fixed it. I don’t know if it’s a fix in libepoxy HEAD, or a bug in brew installation script.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.