FOSDEM09: RandR 1.3 and multimedia processing extensions for X

That would work, but it requires quite a bit of "protocol" between the X
server and the decompressor (select which compressed/uncompressed images
to retain or delete inside the decompressor process).

Getting the concurrency benefits is however more tricky -- if a client
calls "Decompress" in the X server, the X server must delegate the
operation to the helper process, suspend the calling client's request
queue (the X server is single-threaded!), receive completion, resume the
client's request queue etc.

One thing I dislike about the "helper process" approach is that I am not
yet sure how the interface should look like -- currently all decompressors
are for efficiency reasons (cache locality) "iterator-based": you pass
compressed data (as well as decoding dependencies) in, and what you get is
an iterator that traverses the image top to bottom and yields
horizontal "bands" of the image. Currently you receive pixels, usually in
some sort of YCrCb format, which must then be converted to RGB etc. (but
the interface should later also allow getting e.g. DCT coeffecients +
motion vectors for hardware-assisted decode). Mapping this model to the
X/decompressor process is probably not going to work due to excessive
context switches.