[Xr] API questions

[David Forster]

On Thu, Jul 03, 2003 at 10:44:52AM -0700, Bill Spitzak wrote:
> 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.

I think this would be a mistake.

If Xr is to be a serious API for rendering to both CRT/LCDs and
printers, then Xr is going to have to get color management right.
There's no way around it.  If it doesn't, then it'll just get replaced
by someone who's willing to do it right.

The point of abstracting away the hardware is so that developers can
write their rendering code _once_.  The same code used to render a
document (like say a vector/raster image) to the screen can be reused
to print that document out.

If you don't define what the out-of-bounds sRGB values mean, then the
developer is going to have to take over color management, and that
means hardware dependence.  And with Xr already correcting values for
sRGB it will be nothing short of a mess.  One might just as well use
Xr for screen output and PostScript for printer output..

If I where doing this --- and let me say I'm certainly no expert on
this subject, so this is all in my humble opinion --- I would bite the
bullet and provide support for both, say, esRGB (or like expanded sRGB
color space) and CIEXYZ.

Color management would be handled by some unspecified means by Xr.  It
doesn't have to actually do a good job at this early stage, but the
API should get it right.  So one would have:

void XrSetRenderingIntent(XrState *xrs, XrIntent intent);

void XrSetESRGBColor(XrState *xrs, double red, double green, double blue);
void XrSetCIEXYZColor(XrState *xrs, double x, double y, double z);

and for pixmaps there would be appropraite XrFormatSRGB*,
XrFormatESRGB*, and XrFormatCIEXYZ* formats.

The user will then be totally isolated from the underlying hardware,
and should have enough control for ``pro-sumer'' output if not
professional ouput (but again, I'm not an expert).  There would be no
hardware dependent color formats available.

Note that I'm only using esRGB as an example.  I haven't really looked
into what would be the best OOB sRGB color space...

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

If you're doing color management the value isn't going to get passed
straight on anyways.  The overhead of INT->FLOAT->INT is negligible
for individual colors...even less if you just store things as floats
to begin with.  For dealing with pixmaps there is already support for
INT color formats.  I don't see as this would really impact
performance in any meaningful way.

I think it would just cruft up the API...

Just IMHO, though,
-Dave