Skip to content

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

Open
kalzoo wants to merge 1 commit intorust-windowing:masterfrom
kalzoo:try-init-pixel-format-without-profile
Open

fix: CGL: try to init pixel format without explicit profile before falling back to profile selection#1740
kalzoo wants to merge 1 commit intorust-windowing:masterfrom
kalzoo:try-init-pixel-format-without-profile

Conversation

@kalzoo
Copy link
Copy Markdown

@kalzoo kalzoo commented Dec 27, 2025

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

Copy link
Copy Markdown
Member

@kchibisov kchibisov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need changelog entry for that.


// Automatically pick the latest profile.
let raw = [
NSOpenGLProfileVersion4_1Core,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants