[RFC] Visual Class for On-Screen HDR Drawables

[Fredrik Höglund]

On Monday 02 January 2017, Adam Jackson wrote:
> (accidentally sent only to Alex, resending so the list gets it too)
> 
> On Thu, 2016-12-22 at 19:43 -0800, Alex Goins wrote:
> 
> > > One option would be to expose the drawables with existing visuals
> > > through the core protocol, then provide an extension which provides
> > > extended information. That would make everything cross-compatible and
> > > allow new applications to work with existing compositing managers,
> > > although the result would be limited to core X capabilities.
> > > 
> > > I'm pretty uncomfortable with the notion that X can't actually interpret
> > > the pixels as that will make lots of existing software fail, including
> > > many accessibility solutions.
> > 
> > That's a good point regarding the accessibility issue, hadn't considered that.
> > 
> > I actually like this idea. One of the main reasons why I was shying away from
> > the idea of actually covering the new formats with new visual class was that I
> > didn't want us to have to propose revisions to the core protocol every time
> > there's a new format. Using an extension to query extended attributes gets
> > around that.
> > 
> > Would it be worthwhile to still add a new visual class, defined as a visual
> > class for visuals whose extended attributes are queried through the extension,
> > so that applications don't have to use it for every existing visual?
> 
> Either we add a visual class or we retcon the spec for TrueColor.
> Currently the spec says:
> 
> "The red-mask, green-mask, and blue-mask are only defined for
> DirectColor and TrueColor. Each has one contiguous set of bits set to 1
> with no intersections. Usually each mask has the same number of bits
> set to 1."
> 
> The masks are 32-bit integers, so they're not big enough for FP16. I
> don't know if the shared-exponent formats are display formats for this
> purpose, but if they were you could also argue that the exponent should
> be set in all the maks... maybe.
> 
> Likewise X11 defines colors as 32-bit integers. For DeepColor visuals
> we'd probably need to reinterpret those as if they were TrueColor
> representations of the sRGB subset; which is a little weird, since for
> all the other visual formats the "color" is the literal pixel value, so
> again, pretty sure we want a new visual class.
>
> The same "convert to/from sRGB" approach is probably sufficient for
> GetImage/PutImage? I don't think libX11 is set up to handle >32bpp
> pixels correctly, so that might be the best we can do. Given that
> GetImage users are expecting unorm8 anyway...
> 
> Finally, the rop and planemask parts of the GC really don't make sense
> for floats. I'd be inclined to define the new visual class such that
> only GXcopy with planemask ~0 is defined.

We could specify that for core operations, the RGB floating point values
are clamped and converted to integers by multiplying with 2 ^ (the number
of bits set in the corresponding mask) - 1 and then shifted into place and
combined to form a 32-bit TrueColor pixel value.

The purpose of the masks would then be to describe this conversion,
while the actual memory format would be obtained through the extension.

Fredrik