[Xr] API questions

[Bill Spitzak]

On Thursday 03 July 2003 10:25 am, Keith Packard wrote:
> Around 11 o'clock on Jul 3, Carl Worth wrote:
> > The consensus seems to be to support only the sRGB color space and
> > pushing any other color space manipulation up to higher levels. I'm no
> > expert in dealing with color spaces, but I'm accepting that
> > recommendation from those who know more than me.
>
> For those concerned about gamut, it's important to note that the Xr APIs
> accept floating point color values and that these values can be negative.
> While something of a kludge, this will at least provide a representation
> for colors outside the gamut of the non-negative sRGB space.  Of course,
> this would require a new representation of the pixels within Xr, but that
> is less important at this point than getting the API right.

My suggestion is that the exact results for out-of-gamut colors is 
implementation-dependent. This will allow Xr or Xrender to turn the colors 
into internal representation without breaking the spec.

Also whether "get" returns the exact same value sent to "set" is also 
implementation dependent, though it should be true that if you "get" a value, 
use that to "set" the color, and "get" it again, you will get the exact same 
result. This is to allow implementations to store only the internal 
representation of color, but not require it.

Even though it sounds primitive, I would really like to see an 8-bit/color 
interface added, like XrSetColor32(u32 color). This would take a number 
0xRRGGBBAA to specify the rgba. The reason for such an interface is that is 
the way the vast majority of applications are storing color for GUI and also 
how most current devices represent color, and this interface avoids the 
overhead of converting to float and back. I don't think an equivalent "get" 
function is needed.

-- 
                   ,~,~,~,~ ~ ~ ~ ~
     /\_       _|_========___         Bill Spitzak
 ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com