[RFC] Visual Class for On-Screen HDR Drawables

[Alex Goins]

>Either we define the interaction with Render, or automatic redirection
>(and backing store) don't work. But again we're painted into a bit of a
>corner:
>
>typedef struct {
>        CARD16  red B16;
>        CARD16  redMask B16;
>        CARD16  green B16;
>        CARD16  greenMask B16;
>        CARD16  blue B16;
>        CARD16  blueMask B16;
>        CARD16  alpha B16;
>        CARD16  alphaMask B16;
>} xDirectFormat;
>
>Since we can't express the real masks we'd again be forced to operate
>on HDR-destroying sRGB. We could add an internal format that operated
>on the float representation, but we can't expose that to clients
>without a protocol bump.

Would it be a major problem for automatic redirection to destroy HDR?
Compositors could disable automatic redirection for DeepColor windows, and
redirect themselves with preserved HDR.

Clamping to the sRGB range for core and Render operations seems like a decent
compromise for maintaining compatibility and accessibility, while still allowing
HDR compositors to use GLX or EGL to composite preserved HDR. Clamping pixel
values to sRGB8 would be compatible with the current de-facto sRGB8 standard for
normal TrueColor visuals.

One of the reasons why we initially went with the idea of a visual opaque to
core/Render operations is that there are other HDR encodings that have different
transfer functions from the HDR format to sRGB. It sounds like the current train
of thought with clamping to the sRGB range assumes that we are operating only on
the linear FP16 encoding of scRGB, which is highly limiting. scRGB is useful if
we are trying to composite HDR and SDR content together, but there are other
formats as well. Even the scRGB color space has support for a 12-bit nonlinear
encoding in addition to the 16-bit linear one. Android and Windows both have
support for multiple HDR formats.

Say, for example, we're playing a fullscreen video encoded with HDR10 (BT.2020
color space with 10bpc 4:2:0 encoding), and our display takes the same format.
We wouldn't want to have to convert from HDR10 to scRGB and back when we already
have the correct format. That could probably be dealt with via driver tricks,
but without a way to clamp to the sRGB range using the correct transfer
function, it would be broken with core and Render. If we can't encode the
transfer function for arbitrary formats in the visual itself it would have to be
done via the extension, but then we'd have a dependency on the extension for
core and Render operations.

That said, as long as we can figure out how to clamp an HDR format to sRGB,
using the existing masks and colormap as with standard TrueColor visuals should
be fine.


One concern that came up internally is handling pixmaps, which specify a depth
but not a Visual. I looked a bit into Mutter and Compton, and they seem to deal
with this by querying visual properties from the root window, and assuming there
aren't any pixmap-specific parameters that would affect the texture target.
However, since the Pixmap is queried from the Window, they should be able to get
the parameters from the Visual of the Window backing the Pixmap.

The only problematic case would be an app that has a Pixmap of unknown
origin/format and wants to texture from it. For GLX, we might have difficulties
finding a correct fbconfig to create a GLXPixmap to use with glXBindTexImage.
EGL allows you to bind an EGLImage with an opaque-ish format directly to an X
pixmap, so the problem gets pushed into the driver. eglCreateImage(), the
function used to create the pixmap -> EGLImage binding, takes an attribute list,
so we could add a format attribute to avoid guesswork in the driver.

Thanks,
Alex