[RFC] Visual Class for On-Screen HDR Drawables

[Adam Jackson]

On Thu, 2017-02-09 at 19:06 -0800, Alex Goins wrote:
> Any input?

Inline below...

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

It's not a problem in the sense that the actual HDR window content
would still exist somewhere; we just need to be able to do _something_
when an HDR window ends up in Automatic redirection. We could skip
painting it to the parent, we could clamp to some range...

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

Sure. Picking sRGB here is just a plausible default. What we're
trying to cover by exposing HDR content through existing visual classes
and imaging ops is just "do something reasonable for compatibility with
non-HDR-aware apps". If there's some other transformation to unorm8
that would produce better visual results along those paths then great,
we just need to figure out how to expose that to a) application control
b) compositor visibility. There are options there, it could vary by
visual (although I think that's not how GLX visuals want to work), it
could be some new bit of per-window state that we add to Fixes or XC-
MISC or a new extension, it could be a new NETWM property...

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

I feel comfortable saying these compositors are wrong and should be
using glXQueryDrawable to figure out the fbconfig for the window-
pixmap; though, having said that, I'm not sure Xorg's glx would return
something sensible.

But again, I think the colorspace is more properly a property of the
drawable than of the fbconfig. The EGL HDR specs seem to be written in
terms of per-drawable state rather than new configs. So we might need
to add a new attribute for QueryDrawable; that's fine, the set of
people involved in new GLX extension specs are all already on this
list, if not this thread.

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

If this is drawable state not config state, then this difficulty
disappears, right? You look it up from the window whose pixmap you've
bound. Though you do need to get notified if it changes, so we may also
need a new event.

- ajax