[RFC] Visual Class for On-Screen HDR Drawables

[Alex Goins]

Any input?

Thanks,
Alex

On Wed, 25 Jan 2017, Alex Goins wrote:

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