[RFC] DeepColor Visual Class Extension

[Adam Jackson]

On Fri, 2017-07-21 at 20:18 -0700, Alex Goins wrote:

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

The issue I have with refusing to define the TrueColor-like interaction
is that without _some_ guarantees, or at least expectations, the client
is going to have a very difficult time knowing how to set its window
up. How do you interpret a background color or pixmap otherwise?

- ajax