[RFC] DeepColor Visual Class Extension

[Keith Packard]

Alex Goins <agoins at 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
-------------- 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/20170719/11037fc1/attachment.sig>