How do I configure the OpenGL Context on macOS to not be "forward-compatible"?

I would like to get an OpenGL context from GStreamer on macOS that is not “forward-compatible”, i.e. doesn’t remove deprecated OpenGL features.

I am using this command to try out my custom Rust Element:

GST_GL_CONFIG="gst-gl-context-config,forward_compatible=0" GST_PLUGIN_PATH=$(pwd)/target/debug gst-launch-1.0 gltestsrc ! gstreamertest ! autovideosink

But from what I can tell, the context I receive still returns 0 for some configuration values, specifically (code from the wgpu crate):

// ...
max_inter_stage_shader_components: unsafe {
} as u32,
// ...

returns 0 for MAX_VARYING_COMPONENTS, which from what I understand would happen if I get a forward-compatible context, since deprecated APIs are removed from a forward-compatible context, even though they are not removed from the spec or implementation.

I have also tried the following

  • GST_GL_CONFIG="gst-gl-context-config,forward_compatible=0"
  • GST_GL_CONFIG="gst-gl-context-config,forward_compatible=false"
  • GST_GL_CONFIG="gst-gl-context-config,forward_compatible=FALSE"
  • GST_GL_CONFIG="gst-gl-context-config,forward_compatible=no"
    None of which worked, either.

Maybe there is some other way to negotiate a forward-compatible context? Any help would be appreciated.

EDIT: Wrote forward_compatible=1/true/yes but was supposed to write forward_compatible=0/false/no.

OpenGL Profile

I have been researching some more, and I think being able to select a compatibility profile instead of a core profile would work as well, I think.

I used this snippet

let supports_compat = c.supports_glsl_profile_version(GLSLVersion::_410, GLSLProfile::COMPATIBILITY);
let supports_core = c.supports_glsl_profile_version(GLSLVersion::_410, GLSLProfile::CORE);
let supports_es = c.supports_glsl_profile_version(GLSLVersion::_410, GLSLProfile::ES);

println!("Supports compat: {supports_compat}, core: {supports_core}, es: {supports_es}");

Which prints

Supports compat: false, core: true, es: false

So either using a compatibility profile or setting forward-compatibility to false would work, I think.

GStreamer code

I am trying to get a sense of what’s going on in subprojects/gst-plugins-base/gst-libs/gst/gl/cocoa/gstglcontext_cocoa.m, but I can’t find anything related to forward-compatibility in the entire codebase.

GST_GL_API environment variable

I also tried using GST_GL_API="opengl", but that gives me an OpenGL 2.1 context, which can’t be used by wgpu (requires at least OpenGL 3.3 or GLES 3.0).

Using GST_GL_API="opengl3" gives a OpenGL 4.1 context with the core profile on macOS.

I believe on macOS you cannot have an OpenGL 3.x context with the compatibility profile. The GL drivers on macOS do not support that configuration. I’d you ask for compatibility profile, you must use OpenGL 2.x.

Alright, gotcha.

But it seems the forward-compatibility bit is available, since glfw is using that on macos?

See Fixes opengl3 examples on OSX by gordonmcshane · Pull Request #229 · ocornut/imgui · GitHub

If you request an opengl3 context you are requesting a “forward-compatible” context. If you request an opengl context, you are not.

1 Like

There are nuances though, but I think I found a source that agrees with you.

First about the nuances


For OpenGL (3.2+?) there are two profiles - core and compatibility, these profiles could theoretically be available at any OpenGL version at or above 3.2, but it seems like macOS maybe doesn’t implement it this way.

“Forward-compatibility bit”

It seem like it’s allowed in the spec to request a core profile with a forward-compatibility bit set to false. However, the Khronos wiki states:

You should use the forward compatibility bit only if you need compatibility with MacOS. That API requires the forward compatibility bit to create any core profile context.

So you can’t create a core profile on macOS without setting forward-compatibility=true.


I’ve been reading all over different sources that core can be created with the forward-compatibility “bit” set to false. This isn’t possible on macOS, and that’s the important distinction I did not understand until now.

Thank you for your help :heart:

EDIT: added the source