[RFC] DeepColor Visual Class Extension

[Alex Goins]

Inline

On Wed, 19 Jul 2017, Keith Packard wrote:

> * PGP Signed by an unknown key
> 
> 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.

In a perfect world with everything fully implemented I like this idea, since it
makes it obvious where downsampling needs to happen and how to interpret the
downsampled contents.  However, setting it up this way seems to imply to clients
that using DeepColor drawables as SDR TrueColor drawables with core protocol is
just going to work automatically for all operations all the time.

We could add a blurb to the extension nothing that it's done on a best-effort
basis and isn't guaranteed to work as expected, but then clients won't be able
to rely on any defined behavior when operating on DeepColor drawables this way.

I agree that it's important for the spec to be extensible to allow for SDR
downsampling and core X rendering, but if it's a hard requirement for DeepColor
drawables then we could end up delaying the HDR pipeline for man-months just to
implement a use-case that is a sideline to the task of allowing for on-screen
HDR drawables.

Moreover, if we reported these visuals as part of the connection setup block,
they would appear to be identical to the actual TrueColor visuals. How do you
prevent a non-HDR client from selecting a masquerading 'DeepColor' visual? How
do you distinguish them without the extended visual information?

If we left them out of the connection setup block and relied on a separate
request to get a list of DeepColor visuals it would alleviate that issue, but
then we run into the same issue Aaron pointed out with XGetWindowAttributes.
Non-HDR clients would get what appears to be a bogus visual when querying the
visual of an HDR window because xlib would be unaware of it.

We're brainstorming alternate ideas to handle backwards compatibility, and
further suggestions are welcome.

> > 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.

Fair enough. I figured that colorspaces/encodings supported by the
implementation, but not the extension, could be added with a prefix to allow for
extensibility in specific use cases, but it's true that that could add confusion
due to incompatibility between implementations.

I suppose that as long as we have a reasonable set of colorspaces to begin with
and new ones don't come up often, that could work, it will just slow things down
a bit if a new colorspace comes up and applications/compositors want to support
it ASAP. Maybe that's what we want in order to avoid applications becoming
reliant on compositor-specific colorspaces.

> > 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.

OK.

> > 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 transformation would have to be done implicitly by the server, because if a
colorspace disappears, it's ostensibly because the compositor doesn't support
it, so it wouldn't know about how to do the transformation.

> > 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?

A problem here is that without the Present extension, the concept of "next
frame" is poorly defined in X. Specifying what we mean by this in terms of
damage notifications, etc. would prove to be a challenge. Atomic updates could
be left to an interaction with the Present extension, and otherwise would have
to be handled e.g. _NET_WM_SYNC_REQUEST, the same as it is now with regular
damage+composite "frame" handling.

Thanks,
Alex

> -- 
> -keith
> 
> * Unknown Key
> * 0x00000011
>