On Monday 02 January 2017, Adam Jackson wrote: > (accidentally sent only to Alex, resending so the list gets it too) > > On Thu, 2016-12-22 at 19:43 -0800, Alex Goins wrote: > > > > 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? > > Either we add a visual class or we retcon the spec for TrueColor. > Currently the spec says: > > "The red-mask, green-mask, and blue-mask are only defined for > DirectColor and TrueColor. Each has one contiguous set of bits set to 1 > with no intersections. Usually each mask has the same number of bits > set to 1." > > The masks are 32-bit integers, so they're not big enough for FP16. I > don't know if the shared-exponent formats are display formats for this > purpose, but if they were you could also argue that the exponent should > be set in all the maks... maybe. > > Likewise X11 defines colors as 32-bit integers. For DeepColor visuals > we'd probably need to reinterpret those as if they were TrueColor > representations of the sRGB subset; which is a little weird, since for > all the other visual formats the "color" is the literal pixel value, so > again, pretty sure we want a new visual class. > > The same "convert to/from sRGB" approach is probably sufficient for > GetImage/PutImage? I don't think libX11 is set up to handle >32bpp > pixels correctly, so that might be the best we can do. Given that > GetImage users are expecting unorm8 anyway... > > Finally, the rop and planemask parts of the GC really don't make sense > for floats. I'd be inclined to define the new visual class such that > only GXcopy with planemask ~0 is defined.
We could specify that for core operations, the RGB floating point values are clamped and converted to integers by multiplying with 2 ^ (the number of bits set in the corresponding mask) - 1 and then shifted into place and combined to form a 32-bit TrueColor pixel value. The purpose of the masks would then be to describe this conversion, while the actual memory format would be obtained through the extension. Fredrik _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
