[cairo] [RFC] high-quality pixman image downscaling

[Jeff Muizelaar]

On Sat, Jun 27, 2009 at 01:42:56AM +0200, Soeren Sandmann wrote:
> Hi,
> 
> Below are some observations on where image scaling and blurring could
> fit into the pipeline, and how it would relate to the
> downscale-then-transform algorithm in your patch.
> 

[snip]

> A general solution to that would be to make that step configurable by
> allowing users to set:
> 
>    (a) A sample rate for the resampling, given in subpixels per
>        destination pixel, vertically and horizontally.
> 
>    (b) A filter kernel that the subpixels are convolved with.
> 
> This would specify a subpixel sampling grid for each destination pixel
> and a filter kernel with entries in subpixel coordinates. The filter
> in (b) could be given as a symbolic value ('gaussian', 'lanczos',
> 'box') along with a size, so that the implementation could take
> advantage of separability etc.
> 
> Having this feature would fix several issues:
> 
>    * Very high quality image scaling if you do the full compositing
>      and filtering in one pass, but still allows the two pass
>      scale-then-full-compositing.
> 
>    * Higher quality gradients. Currently gradients with high-frequency
>      color changes can cause bad aliasing. Super sampling them would
>      help with that.
> 
>    * Support for blurring, which was a recent feature request for
>      cairo.

Do you envision this filtering happening per destination scanline or pixel?
i.e.

    for each destination pixel
       fetch associated src pixels
       filter src pixels to produce destination pixel

                        or

    for each destination scanline
        for each y-sample line associated with destination scanline
            fetch associated src pixels and store in temporary buffer
            filter temporary buffer in x-direction producing a filtered y-sample
        filter y-samples to produce destination pixels

I fear doing it per pixel will be too slow to be very useful, though I could be surprised.

> Also note how a future polygon image would fit in. The antialiasing
> that cairo currently does is precisely equivalent to resampling with a
> 15x17 box filter, so if we added a polygon image, this new interface
> would naturally apply to it. Aside from the blurring usecase, better
> filtering for polygons is interesting anyway to reduce aliasing at
> almost-axis-aligned edges.
>

[snip]

> So if we need a way to have general resampling filters anyway, it
> probably does not make sense to have a separate downscaling API that
> would have a subset of the general functionality. 

My biggest fear with the general approach is that we'll end up with a bunch of
code that isn't used. If cairo adopts the two pass approch, I'm not sure who
would use or take advantage of the more general code paths.

> I do like the idea of first rescaling, then running the general
> compositing, but it seems like if we had the resampling filters along
> with your rescalers as fast paths for the scale-only case, it would be
> doable without any other new API. I have not yet read the code
> carefully, so it's entirely possible that I'm missing some reason this
> wouldn't work.

I haven't thought very much about external API or how exactly downscaling
should be be plugged into cairo yet. Currently, I'm more concerned about what
the interface to the fast-pathed filters should be. Is it ok too keep my
proposed interface but leave it as an internal interface until we've resolved
what the external api should look like?

-Jeff