[RFC] Visual Class for On-Screen HDR Drawables
Keith Packard
keithp at keithp.com
Wed Dec 21 19:35:35 UTC 2016
Adam Jackson <ajax at nwnk.net> writes:
> 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.
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.
> 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.
--
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161221/8b79b9fe/attachment.sig>
More information about the xorg-devel
mailing list