> >> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
