[RFC] Visual Class for On-Screen HDR Drawables

[Alex Goins]

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

Fine by me.

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

What I meant is that the compositor starts with a plain X drawable, then uses
the attributes in the X visual to find a matching fbconfig and create a
corresponding GLX drawable. Without a way to query that we have, say, FP16
components as opposed to 8-bit unsigned fixed-point components, getting the
correct fbconfig would be a challenge. The attributes we need would be in the
fbconfig, but we need a way to get there first.

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

Aaron would probably be able to provide more input here regarding how the NVIDIA
driver handles the mapping between existing fbconfigs and visuals.

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

Yes.

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

Thanks!
-Alex