[Xr] API questions
spitzak at d2.com
Thu Jul 3 10:44:52 PDT 2003
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
More information about the cairo