Recommended way of loading OpenGL functions in GTK4 apps?

Platform
,
1

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.

2

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

1 Like
3

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?

4

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.

5

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.

6

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

7

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
...
8

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

9

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.

10

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