Road map for remaining pixman refactoring

[Simon Thum]

Soeren Sandmann wrote:
>     - bits_image_fetch_pixels() then calls a low-level pixel fetcher
>       whose job it is to convert from whatever the image format is to
>       PIXMAN_a8r8g8b8.
Just a question: does that imply algos will work on 8-bit data? I'm 
asking since that would block the easy path to gamma-correct ops which 
you already explored in the gamma branch.

I'd be volunteering to add a lut to that & make it env-configurable 
(though not before end-of-year), but that would require staying at 16 
bit processing.

Also, I'd like to take the chance to comment on some things in the 
refactoring document:

> 	- Luminance vs. coverage for the alpha channel
> 
> 	  Whether the alpha channel should be interpreted as luminance
>           modulation or as coverage (intensity modulation). This is a
>           bit of a departure from the rendering model though. It could
> 	  also be considered whether it should be possible to have 
> 	  both channels in the same drawable.
I think that coverage is the way to go. Luminance (most likely what is 
meant is Luma: http://en.wikipedia.org/wiki/Luma_(video)) is scaled by 
simply multiplying components by one factor; in other words, there is 
always a coverage which corresponds to a chosen luma factor inside 0..1.

Scaling outside of 0..1 shouldn't be pixman's business IMO.

> 	- Alternative for component alpha
> 
> 	  - Set component-alpha on the output image.
> 
> 	    - This means each of the components are sampled
> 	      independently and composited in the corresponding
> 	      channel only.
> 
> 	  - Have 3 x oversampled mask
> 
> 	  - Scale it down by 3 horizontally, with [ 1/3, 1/3, 1/3 ]
>             resampling filter. 
> 
> 	    Is this equivalent to just using a component alpha mask?
If I got it right, this is basically how one creates a component-alpha 
image. As I view it, component-alpha should be a 'mastered' 
representation, a final step before compositing. IOW, except for 
compositing there is nothing sensible to do with component-alpha images. 
This is simply so because CA images already encode the anticipated 
layout of the components on screen.

So what you're describing is not an alternative, but the preceding step. 
Maybe you could clarify the intent a bit?

Cheers,

Simon