fix: CGL: try to init pixel format without explicit profile before falling back to profile selection

[kalzoo]

• Tested on all platforms changed
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality

Note: I am not experienced with OpenGL. This contribution fixes a bug "on my machine" but I can't say for certain that it is correct in general.

---

Problem

On macOS, the current implementation always adds NSOpenGLPFAOpenGLProfile when creating pixel formats, then iterates through profiles (4.1 Core, 3.2 Core, Legacy) until one succeeds.

This differs from GLFW's behavior. When GLFW receives no explicit GLFW_CONTEXT_VERSION_* hints, it does not add NSOpenGLPFAOpenGLProfile at all (see nsgl_context.m here and here )

The difference matters because:

• With explicit profile: macOS returns a strict context matching that profile
• Without profile attribute: macOS selects a "best compatible" context that may expose both legacy fixed-function GL features AND modern extensions like ARB_framebuffer_object

This causes compatibility issues for applications that need both fixed-function OpenGL (only available in Legacy profile) and ARB_framebuffer_object (not exposed as an extension in strict Legacy mode, only in 3.0+ or unspecified contexts).

In my case, that was mujoco-rs, issue here.

(Red herring - same error message, but not caused by or using glutin: google-deepmind/mujoco#1778 )

Solution

So, I changed that section to try creating the pixel format without any NSOpenGLPFAOpenGLProfile first. If that fails, fall back to the existing/previous explicit profile iteration.

Testing

Tested on macOS with applications using MuJoCo physics engine rendering, which requires both fixed-function GL and ARB_framebuffer_object. Previously failed with OpenGL ARB_framebuffer_object required error; now works correctly. Also, cargo test passed. No other testing performed.

[kchibisov]

Need changelog entry for that.

[kchibisov]

Can you make it into e.g. [(0, 0), (NSOpenGLProfileVersion4_1Core, NSOpenGLPFAOpenGLProfile), ...] so we don't have this back and forth. It doesn't really matter how many elements we have as long as its terminated with len.

[davidhozic]

Not sure if the PR author is subscribed to the PR thread. Perhaps you can modify it manually @kchibisov? This would be a nice to have fix since it completely blocks macOS visualization from working in my crate.

[davidhozic]

Any news on this @kchibisov ?

[kchibisov]

you can apply suggested changes, test and open a PR? I don't have macOS to test, so leave it to someone affected with said problem

[davidhozic]

you can apply suggested changes, test and open a PR? I don't have macOS to test, so leave it to someone affected with said problem

I'll apply some changes and test them tomorrow. Looking at this PR again, it seems to kinda break some stuff for existing users as macOS. Specifically, it will select an older OpenGL version.

I'll try to add some sorts of configuration, with the default staying the same.