Alex Goins <ago...@nvidia.com> writes: > 2. DeepColor Visual Class > > The DeepColor extension defines a new visual class, DeepColor.
As Adam says, reporting a new visual class to existing clients may well confuse existing applications. What I'd love to see is to have these clients report 'TrueColor' in the core, with a 'real' set of red/green/blue masks, such that calling GetImage would give you bits in that format. Then you'd offer 'extended visual information' about the visuals which would tell you about the real format. This would provide well-defined semantics for the core protocol, including things like GetImage. > Possible colorspace/encoding atoms include, but are not limited to: I think the extension should specify precisely the set of color spaces supported; if you want to add more, the extension would be revised. Otherwise, there's no way to make things interoperate correctly. Given that, there's no particular reason to use ATOMs instead of defining constants for the color spaces. > Implementations may choose to add additional atoms to this list. Adding color spaces should require changes to the spec so that clients can figure out what's going on. > It is the application's responsibility to listen for PropertyNotify events to > determine if the set of supported colorspace/encodings changes, and adjust its > rendering accordingly. This could occur due to an external compositor being > launched or killed, or due to a modeset. What happens if you have a window using a colorspace which disappears? If we have a defined transformation from each color space to the exposed TrueColor visual, then would it be sufficient to just have the display fall back to that? > The application may change this window property to any colorspace/encoding > from > the applicable set of supported colorspace/encodings at any time. Compositors > must listen for PropertyNotify events to determine if and when an application > changes _DEEPCOLOR_COLORSPACE, and adjust their composition > accordingly. It seems like we'd want an atomic mechanism to update the content and the colorspace at the same time, so you could do a page flip and get the content updated? Otherwise, I think we've got a pile of possible flashing on the screen? Maybe define the property as being what encoding the *next* frame will be? -- -keith
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel