Problem description

Most OpenGL apps and virtually all games use the sRGB color space internally, but currently glfw does not perform the setColorSpace call on newly created Windows as SDL and Filament does. This is a problem because Apple machines are often used with wide-gamut displays, typically displays that operate in the DCI-P3 color space natively. This results in all glfw apps appear with the wrong gamma (usually resulting in a darker image) and way oversaturated colours if the system-wide colour space setting is something else than sRGB (typically DCI-P3 on macOS).

Contrary to other OSes, macOS has very good built-in system-wide colour management. However, OpenGL windows do not get colour-corrected by default—it's opt-in, you must do that explicitly with a [win setColorSpace:[NSColorSpace sRGBColorSpace]] call. The colour space you set must be the internal colour space of your OpenGL application (sRGB for 99% apps out there), otherwise the colours will appear wrong if the device colour space is different (typically DCI-P3 on macOS machines). As mentioned, SDL and Filament hardcode this call because that's simply the 99% use case today (see links in the Sources section).

Proposed solution

Just insert the below line somewhere into createNativeWindow in glfw/src/cocoa_window.m after the window has been created:

[window->ns.object setColorSpace:[NSColorSpace sRGBColorSpace]];

An even better solution would be to make this optional via a hint or something, and have the hint default to enabled. The reason is some applications might take colour management matters into their own hands. But this is not too important for now; the hardcoded solution suffices for the 99% use case, and arguably a proper colour management API is the real solution (e.g., something that is being introduced to SDL3 right now).

Example

I am using a wide-gamut monitor running in its native DCI-P3 colour space, then I have the appropriate colour space set for the monitor in the macOS system preferences:

This way sRGB content appears correctly system-wide (in video players, image viewers, browsers, etc.), and I can still take advantage of the wide-gamut colour space in applications that support it.

The following screenshots were taken from my program, Gridmonger, which is built on top of glfw and uses OpenGL rendering for the entire UI.

Note that you can only view these images as intended on a DCI-P3 monitor running in native DCI-P3 mode. On an sRGB monitor, or a wide-gamut monitor running in sRGB emulation mode, the "wrong" image will appear correct, and the "correct" image will look washed out—but the important point here is that you can view the difference even if you only have a non-wide-gamut sRGB monitor.

Current glfw behaviour (wrong)

The image appears too dark and too saturated on DCI-P3 displays (but will appear correct on sRGB-native displays).

Fixed glfw behaviour (correct)

I made this screenshot with a patched version of glfw where I've added the [win setColorSpace:[NSColorSpace sRGBColorSpace]] call.

The image appears with the correct brightness (gamma) and colours on DCI-P3 displays (but will appear washed-out and desaturated on sRGB-native).

Side notes

• Games supporting HDR might use DCI-P3, or they might not. HDR is not the same as wide-gamut.
• Introducing a robust colour management API is difficult, especially because macOS, Windows, and Linux all have different approaches to colour management. However, this would be a good first step to cater for the 90% use case on macOS. Now the 90% use case on macOS is broken on DCI-P3 and similar wide-gamut monitors.
• Wide gamut displays are only getting to be more widespread going forward, so at some point proper support must be added. The SDL project has taken steps to do that in version 3, e.g., see here.

References

• StackOverflow: https://stackoverflow.com/a/68656776
• Filament: https://github.com/google/filament/blob/main/libs/filamentapp/src/NativeWindowHelperCocoa.mm
• SDL: https://github.com/libsdl-org/SDL/blob/05ce978e1892bd928648d326daffed8d1fd06adb/src/video/cocoa/SDL_cocoawindow.m#L2479