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 _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman