[cairo] Concerns about using filters for downscaling

Owen Taylor otaylor at redhat.com
Fri Mar 21 20:26:22 PDT 2014

On Sat, 2014-03-22 at 03:24 +0100, Krzysztof Kosiński wrote:


> >  * On a hardware backend, running even a large convolution filter in
> >    a shader is likely possible on current hardware, but it's not
> >    taking efficient use of how hardware is designed to sample images.
> >
> > Here are my suggestions with an eye to getting a release of 1.14
> > out quickly
> >
> >  * The convolution code is restricted to the BEST filter, leaving
> >    GOOD and BILINEAR untouched for now. The goal in the future
> >    is we'd try to get similar quality for all backends, whether by:
> >
> >     A) Triggering a fallback
> >     B) Implementing convolution with the same filter
> >     C) Using an entirely different technique with the similar
> >        quality.
> This would make Cairo 1.14 completely unusable for Inkscape, so we
> would have to postpone the long overdue 0.91 release for another year
> or more, and probably stop using Cairo.

I don't quite understand this - presumably 0.91 will be the same in this
regard as previous versions of Inkscape. Is there some work-around in
older Inkscape that you are trying to remove?

But certainly my interest is also to actually get a Cairo release out in
a finite amount of time.

> The downscaling method used in
> 1.12 is simply incorrect and due to severe visual artifacts makes it
> impossible to use Inkscape to edit drawings that contain large
> bitmaps, e.g. photos. It's no use being fast if the result is wrong.

Hmm, can you use BEST? That seems to be the right constant to use if you
quality is the absolute requirement and performance is secondary.

If we followed my plan, that would work for:

 old versions of cairo: same old bilinear sampling
 1.13 snapshots as in Fedora 20: LINEAR/BOX convolution 
     (due to the missing break)
 1.14: LINEAR/BOX or something of that approximate performance
The only problem would be that Inkscape would continue to be using BEST
even if the user upgrades to a version of Cairo that has a mipmap'ed
or other form of pretty-but-fast GOOD. For that, I'd suggest that
Inkscape could then be altered to do:

 filter = cairo_version() < CAIRO_VERSION_ENCODE(1,16,0) ?

Ugly, but works.

I don't think releasing 1.14 with the default filter 5-10x slower is
acceptable - it's better for applications to have the problems they know
(and may have worked around) then to introduce different problems.

So the other alternative would be to try to implement mipmapped image
sources in the different backends now. To me that seems like a
substantial development effort. There's no reason that a 1.14 now can't
be followed by a 1.16 in a few months - is other destabilizing work
happening or planned?

- Owen

More information about the cairo mailing list