[Pixman] sRGB processing for pixman

[Antti S. Lankila]

Hello everyone,

I have worked out a tentative patch to pixman which adds capability for 
processing images in sRGB color space. This is still somewhat a 
work-in-progress, but the basic functionality should be there.

Here's a quick overview of the content of the patch:

- PIXMAN_FORMAT tag is extended by splitting the 8-bit TYPE to two 4-bit 
values, where the first one is a new colorspace value. The macro and its 
users are redefined to handle this. (Could cause minor source-level 
incompatibility, as at least xorg's xrender module seems to use 
PIXMAN_FORMAT macro directly.)

- two color spaces are supported, 0 for linear-with-sRGB-gamut and 1 for 
sRGB.  The texture format for sRGB is premultiplied alpha with the 
multiplication factor itself gamma-corrected, as described here: 
http://ssp.impulsetrain.com/2011/08/10/gamma-correction-vs-premultiplied-pixels/

- internally, sRGB color space usage triggers "wide" processing. 
Afterwards, pixman_expand and _contract functions notice the color space 
value and transform the values.

- accessor method for color space of image is provided in the pixman api.

- simple srgb-demo is provided under demos. The demo simply alpha blends 
two opposite colors, #f0f and #0f0 together, and the midpoint in 
gamma-aware processing is not #888 but around #bbb.

The eventual goal of this work is to add support for sRGB surfaces in X 
and then to patch various text-rendering libraries in Linux to use these 
surfaces to generate improved quality in font rendering. With sRGB 
processing, color fringing of LCD text should be history, and any excess 
darkening (because of the #888 vs #bbb problem) of antialiased lines and 
curves should become solved. Later on, graphics drivers should add 
capability to handle the a8r8g8b8_sRGB surfaces natively to allow 
hardware acceleration of the composition.

Currently the color space processing is just a cheap integer hack with 
gamma 2.0. It is sufficient for testing purposes, but not production 
quality. I'm leaning towards tabularizing the official sRGB-to-linear 
function and its inverse in a future patch.

The current version of the patch can be downloaded from this URL for 
now, and I'm looking for feedback:

http://bel.fi/~alankila/0001-Add-tentative-support-for-sRGB-surfaces.patch

-- 
Antti