[Pixman] [cairo] Planar YUV support

[Benjamin Otte]

On Thu, 2010-05-13 at 22:02 +0200, Soeren Sandmann wrote:
> I do think that interpolation should not be the
> responsibility of the sample fetchers though because that ultimately
> leads to them having to deal with fractional positions.
> 
Yeah, I fully agree here. I think what we should have is two sets of
sample fetchers: The current pixel ones and a component-wise fetcher.
And we allow one of them to be NULL.
Then we just need a way to map fractional pixel values to components and
we can write a bits_image_fetch_transformed_components() and use that if
if the pixel fetcher is NULL.

> Conceptually, the alpha value represents coverage, whereas
> (unpremultiplied) color values represent how much of that color is
> reflected back with 0 meaning all light is absorbed and 1 meaning all
> reflected. This means the total amount of light reflected back at the
> sample point is alpha * channel. The amount of light reflected back at
> an intermediate position then is the intermediate between the two
> (alpha * channel) values.
> 
I spent a while doing the math, and you are right.

I suppose it's not an issue for most YUV formats as they are all opaque,
but there are some. In particular AYUV that GStreamer uses a lot. And
I'd like that to not slow to a crawl when compositing. But we can solve
that problem when people actually composite onto it.
  
> Another possibility is to get rid of the scanline fetchers and use
> get_pixel() exclusively. In some sense this is the more fundamental
> operation, and fetch_scanline() could be considered an
> optimization. (And Toshok's gradient work would actually allow them to
> be treated as such).
> 
I've not benchmarked it, but my gut feeling tells me that pixel-wise
fetching is quite a bit slower in a few cases that we still need and
scanline fetching is not a lot of overhead, so I'd advocate keeping the
scanline fetcher. But yes, it's a specialization of get_pixel already.
That said, removing one will get my vote, no matter which one. :)

Benjamin