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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
