[RFC] Visual Class for On-Screen HDR Drawables

[Adam Jackson]

On Fri, 2016-12-16 at 18:44 -0800, Alex Goins wrote:

> 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.
> 
> VoidColor is a visual class defined to have a static colormap of 0 elements.  It
> is incapable of receiving X rendering, but is compatible with any GLX drawable
> of the correct depth regardless of other attributes. The idea is that you could
> pass any GLX fbconfig to glXCreateWindow as long as the corresponding Window has
> a VoidColor visual with a matching depth.

I think I'd prefer DeepColor as a name? It does clash acronyms with
DirectColor, but "void" is a bit misleading. This sounds pretty
reasonable though.

> Such a design would likely prevent X Render compositing

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.

> One concern we have is the texture_from_pixmap extension. The
> current pattern compositors such as Mutter and Compton seem to use is to look up
> an X drawable, create an intermediate GLX drawable, and use that for
> BindTexImage. If we don't store distinguishing attributes in the Visual,
> compositors would have trouble creating a correct, matching GLX drawable.

Can you elaborate? What distinguishing attribute would you need, and
why is it not a property of the fbconfig? (I suppose there's an
ambiguity here between the fbconfig the app uses for the window, and
the fbconfig the cm uses for the pixmap, but if they're the same...)

> Perhaps the compositor could wait for the application to create a GLX drawable
> before querying it, but there would have to be some mechanism to know when it's
> ready. The alternative would be to store distinguishing attributes in the
> Visual, but that would mean limiting it to fbconfigs that can be differentiated
> by those attributes, and would necessitate the creation of many visuals to match
> the fbconfigs, which we are trying to avoid.

I don't think this is true, the "necessitate the creation" bit. The map
from fbconfigs to visuals is surjective, you're allowed to have more
than one config compatible with the same visual. Or at least, GLX
allows this; maybe you know of applications or middleware that assume
otherwise? (And if you do, does it matter? They can't be doing deep
color to the window today, they're going to need changes anyway.)

I think this also implies adding >32bpp pixmap depths: the named window
pixmap has to have _some_ depth.

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.

- ajax