Adam Jackson <[email protected]> writes: > 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.
I think we have to expose the windows through the core protocol using the existing visuals, and make GetImage/PutImage transform between sRGB TrueColor and the "real" format. > 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... Yup. > 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. It's either that or define all core rendering in terms of the transformed sRGB unorm pixel values? That almost seems worse. And should we define Render to work "right" with these formats? -- -keith
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
