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