Add Display P3 color space support for macOS

[TNTpower0v0]

Hi! I did this with the help of AI, but I wrote the code myself. Everything is working well on MacOS, and my friend with Windows and Linux has also confirmed normal colors.

• Adds native Display P3 color space support for modern mac displays (fallback for compatibility for older/differen conf. macs)
• Enables GLFW_COCOA_RETINA_FRAMEBUFFER to guarantee native resolution rendering on Retina displays
• Extended Color Depth. 10-bit color (10+10+10+2 format)

[cadenkriese]

Fixes #198 for me

[tankonatorinweb]

It’s working for me

[tankonatorinweb]

@xCollateral is it possible?

[TNTpower0v0]

@BloCamLimb so its absolute incorrect to make?

[BloCamLimb]

I don't think this PR actually fixes the root cause; in fact, it's essentially replicating a known color management flaw.

The "vibrancy" experienced in the OpenGL version (Vanilla/Sodium) is a side effect of a long-standing GLFW bug glfw/glfw#2748 (or rather, a lack of implementation) where it fails to call setColorSpace. On macOS, this causes the WindowServer to treat raw sRGB values as if they were already in the Display P3 gamut. This "stretches" the colors, resulting in over-saturation that might look "better" to some, but is technically a bug.

The "muted" look in Vulkan is actually the correct, calibrated behavior. The system is properly remapping sRGB values to the P3 display so that a red in your app looks like the intended red, not an over-saturated version of it.

By simply switching the Swapchain to P3 without adding a proper color space conversion pass in the shader, this PR is just matching one mistake with another. You're interpreting sRGB data as P3 coordinates, which is mathematically incorrect and breaks platform consistency.

The implications of merging this:

• Loss of Accuracy: We lose the ability to display "true" sRGB colors.
• Platform Inconsistency: The app will look completely different on a P3 Mac compared to a standard sRGB monitor or Windows/Linux, where the sRGB-to-P3 "stretching" won't happen.
• The "Fake" Fix: We are choosing a "pleasing" bug over a correct implementation.

If the goal is to truly support the P3 Wide Gamut, we shouldn't just toggle the Swapchain. A real wide-gamut implementation requires a much deeper architectural shift:

• P3-Aware Offscreen Buffers: All offscreen render targets and intermediate buffers should be set to the P3 color space to prevent clipping.
• High Precision Textures: We should utilize RGBA16Float (F16) textures to provide the necessary headroom and precision for the expanded color volume, avoiding banding in the wider gamut.
• Proper Color Transform: We must implement a dedicated color management pass in the fragment shader to transform coordinates from sRGB to P3.

Without these steps, we aren't "supporting" P3; we're just abusing the wide gamut to mask an sRGB calibration issue. I suggest we revert this (since this is already cherry-picked) and stick to a standard sRGB workflow until we are ready to implement a full-pipeline wide-gamut solution.

@BloCamLimb so its absolute incorrect to make?

Yes

[TNTpower0v0]

@BloCamLimb Thx for comment

[TNTpower0v0]

@BloCamLimb But i stull think some people playing vanilla with broken colors and just used to it. For the same reason, I didn't notice the incorrect colors and ended up repeating the mistake.

[BloCamLimb]

@TNTpower0v0 This issue should be reported to Mojang. If they don't address this legacy behavior, players will continue to mistake broken (stretched) colors for "correct" ones.

This is quite easy to fix in OpenGL side, adding these few lines of code during window initialization

NSWindow *window = (NSWindow *) glfwGetCocoaWindow(glfwWindow);
[window setColorSpace:[NSColorSpace sRGBColorSpace]];

long windowPtr = GLFWNativeCocoa.glfwGetCocoaWindow(glfwWindow);
NSObject window = new NSObject(new Pointer(windowPtr));
Client client = Client.getInstance();
Object srgbSpace = client.sendProxy("NSColorSpace", "class").sendProxy("sRGBColorSpace");
window.send("setColorSpace:", srgbSpace);

[cadenkriese]

Thanks for finding the root cause that's very interesting. I'm in favor of merging this PR anyway to match vanilla behavior because that's the way the game has looked on Mac for years, and the one users have come to expect. Plus if the glfw issue gets fixed in the future then VulkanMod can easily revert and match.

Full P3 support is a different issue that I personally don't care about until after VulkanMod support custom shaders (I believe Iris has this).

[xCollateral]

I agree with @BloCamLimb, the game is meant to be rendered in sRBG color space, mapping the output as is to P3 isn't a correct solution.

Anyway this PR was meant to reproduce vanilla behavior, which macOS users have come to expect. I don't think that forcing P3 is correct, the only workaround for now might be to let users choice which color space they want to use.