Color management getters/events

[Ralith]

Description

Applications (e.g. games, image viewers, video players) capable of native HDR output may be able to provide better visuals by querying the compositor and/or display's color reproduction capabilities and state. Useful information includes, but is not limited to, the minimum and maximum luminance and the reference white level. For example, this can help a game ensure its UI is displayed at the same brightness as the user's desktop GUI elements, and help minimize clipping/distortion of out-of-range luminance.

On Wayland, this is available via the recently merged color-management-v1 extension, in particular wp_color_management_output_v1::get_image_description and wp_color_management_output_v1::image_description_changed. On Windows, the reference white level is available via QueryDisplayConfig with DISPLAYCONFIG_SDR_WHITE_LEVEL, and other data is available in DXGI_OUTPUT_DESC1, though I'm not sure if DXGI APIs are usable from winit.

Additional research is needed to determine the full scope of metadata that should be exposed (e.g. are primary chromaticities useful?) to avoid future churn. The Wayland protocol has had a lot of thought put into it and may be a good model, and also cites relevant standards also used in image/video formats.

Graphics APIs already expose mechanisms to declare the properties of HDR content that an application actually generates, independent of the display, e.g. VK_EXT_hdr_metadata, so perhaps no special support from winit is required there although e.g. Wayland does seem to also have similar functionality. It's not immediately obvious how the two different mechanisms for applications to advertise this info interact.

Relevant platforms

Windows, Wayland

[kchibisov]

I think it's a matter of a WSI you're using and not winit in particular, like the wayland color management protocol will be implemented in mesa, and thus will be available to you by its means.

[kchibisov]

The hdr vulkan extension will work via the new wayland protocol on wayland. You can browse mesa PRs to see how it's done.

[Ralith]

I think it's a matter of a WSI you're using and not winit in particular

I think winit has to be where the getters/event forwarding live. Graphics API WSIs don't expose properties of the display environment, only tools for declaring the properties of your own content.

The hdr vulkan extension will work via the new wayland protocol on wayland

Ahah, that makes sense, thanks!

[IsaacMarovitz]

This is also essential for macOS. Currently, NSWindow.colorSpace is not exposed, which causes windows to default to P3, even if the intended content is HDR. This causes colours to be overly bright and saturated. This manifests in apps like Servo which incorrectly display SDR content.

[kchibisov]

You don't need a winit patch for that to work in servo, just set colorspace on the view yourself. We do so in alacritty for example, basically a one line.

    let view = match window.window_handle().unwrap().as_raw() {
        RawWindowHandle::AppKit(handle) => {
            assert!(is_main_thread());
            unsafe { handle.ns_view.cast::<NSView>().as_ref() }
        },
        _ => return,
    };

    unsafe {
        view.window().unwrap().setColorSpace(Some(&NSColorSpace::sRGBColorSpace()));
    }

[IsaacMarovitz]

You don't need a winit patch for that to work in servo, just set colorspace on the view yourself. We do so in alacritty for example, basically a one line.

Servo has no direct dependency on objc2_app_kit, rather than adding one, it would be better for this to be handled properly cross-platform.

[kchibisov]

What you're talking about is macOS specific issue, what was proposed here is a different matter which is used by presenting API. There's nothing to handle cross platform, since it's macOS specific behavior, and every other display system has sane default. macOS just shifts colors because it wants so.