[RFC] Visual Class for On-Screen HDR Drawables

[Alex Goins]

> >> To allow for scRGB visuals, as well as others with arbitrarily large color
> >> components, we'd like to propose a new visual class that is opaque to X
> >> rendering, but allows for drawables with arbitrary attributes to be used for
> >> on-screen rendering and compositing via GLX. I'll call it VoidColor, for now.
> 
> I'd love to just see new visual types defined that cover the new
> formats, or at least picture formats. Pretty much anything that has a
> fixed number of bits for each pixel can be mapped to a visual as the
> only requirement for a visual is that it map the bits for a pixel to an
> RGB value.
> 
> 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?

> > Maybe more like "does not address" than "precludes". Pixmaps are just
> > piles of bits after all, if we had 48- or 64-bit pixmap depths we could
> > easily add corresponding picture formats to a new version of Render.
> > And I think we need those (pixmap) formats anyway, see below.
> 
> If you've got picture formats, you can have visuals.
> 
> > I was pretty vocally wary of deep color visuals at XDC but I think I'm
> > coming around to it, especially with the static colormap limitation.
> > The GLX part of the design can be whatever we need. I think there are
> > some new failure modes this could introduce in the actual Composite
> > part of the implementation; I'll meditate on that over the holiday.
> 
> Offering deeper formats that could include floating point components
> seems like a fine plan.

Yeah, it seems a lot less hacky than the current proposal, and best of both
worlds if we can query that information via an extension.

Thanks,
Alex