[Openicc] XICC specification draft

[Craig Ringer]

On Sat, 2005-06-25 at 16:54 -0600, Chris Murphy wrote:
> Could someone explain to me how remote display works? Where is the  
> rendering and compositing occurring? On server or client?

Sure. I'm no expert, but I'll see if I can provide some info.

The X server runs on the machine the user actually sits at. It's job is
to send input to the X client programs, wherever they may be running,
and to draw what the X clients ask it to draw. It also has other
features such as facilitating client<->client communication.

X clients may be local, or they may be remote (say, running on a
terminal server). This leads to the situation, confusing at face value,
that the X server runs on a (potentially thin) client and displays X
client programs running on the (maybe terminal) server.

Rendering can be done both client and server side. Generally a client
will render a bitmap and use X11 to tell the server to draw the bitmap
if it needs to do more complex drawing than the X server can understand.
For simpler drawing, it'll send drawing requests over the X11 protocol
and the X server will do the rendering. The RENDER extension improved
the X server's ability to draw server side, so some things - such as
antialiased fonts - that would've required client side bitmap creation
can be done server side instead.

Things like the X Composite extension that are being developed currently
further extend the X server's abilities. Future extensions are possible
- for example, CMS support in the X server its self would probably
involve an extension so that clients could query and control the X
server's CMS. Because clients can query for extensions and only use them
if present, extensions let the X11 protocol be extended in a backward
compatible way - server-side CMS support, for example, could be added
without breaking clients that weren't aware of it.

Currently, the client has to make all colour decisions client side and
send colour information in the target device colourspace. It's
the /client's/ responsibility to convert all input colour spaces to the
device colour space when sending data to the X server, since the X
server is unaware of ICC or colour spaces other than its own. The client
can use something like the xicc atom to discover the server's display
profile, though, ensuring that no matter where the client is executing
it always gets the display profile for the X server that its output will
be displayed by. This lets the client do /correct/ colour transforms and
give the X server colour data in its colourspace that's adjusted to
produce the desired result when displayed.

> If it's all done on the remote client, then it would be perfectly  
> acceptable to NOT include the entire source ICC profiles for each  
> object to be displayed, in the case of output device profiles.

That's right - the X server doesn't need to know or care about them.

--
Craig Ringer