[cairo] [PATCH] Revert "image: Use convolution filters for sample reconstruction when downscaling"
Bryce W. Harrington
b.harrington at samsung.com
Thu May 15 23:59:53 PDT 2014
On Wed, May 14, 2014 at 02:54:35AM +0200, Krzysztof Kosiński wrote:
> 2014-05-13 10:15 GMT+02:00 Uli Schlachter <psychon at znc.in>:
> > This reverts commit fb57ea13e04d82866cbc8e86c83261148bb3e231.
> > When running cairo-test-suite with the parameter "-a", it also runs each test
> > with a non-zero device-offset and device-scaling. The above commit influenced
> > the device-scaling results badly. E.g. some test results ended up with a black
> > border at the top-most and left-most row that looked like there was an offset of
> > "0.5" in drawing the image and thus pixels outside of the image were sampled.
> > This can be seen by the influence that this revert has on the results from
> > running CAIRO_TEST_TARGET=image ./cairo-test-suite -a:
> > Before: 31 Passed, 489 Failed [1 crashed, 8 expected], 31 Skipped
> > After: 225 Passed, 295 Failed [1 crashed, 8 expected], 31 Skipped
> > Most of the failures that disappeared are from the device-scaling tests.
> > With such disastrous results on the test suite, this cannot really be usable for
> > real-world applications.
> Without some way to use convolution-based downscaling, we cannot
> release Inkscape 0.91, since working with large bitmaps (e.g. photos)
> is impossible due to extremely poor output quality, and that is a core
> use case. This is very bad news.
These are some good points, and I definitely sympathize with where
you're coming from. I'd also like to see this bug gone in Inkscape.
It would be bad to release 0.91 with a known issue that regresses some
of our users.
But quite similarly and understandably, neither does the Cairo project
wish to put out a release with a known issue that regresses some of
Something else to keep in mind. From Inkscape's perspective, we do have
several ways to work around this problem. We totally control the
packaging situation here. For Win and OS X we already distribute cairo
with our binary packages, and can include whatever patches on top of
stock cairo that we think best. Even on Linux, since both cairo and
inkscape missed the LTS cycle, we'll have to provide both packages via a
PPA anyway (regardless of whether the downscaling patch goes in), and so
can patch the cairo we provide however we want.
But this is a worst case scenario. I would like to think there is a
muutally agreeable approach that would solve this in Cairo. I don't
think anyone has suggested this problem is not something that needs
fixed; it's just disagreement over definitions of the various levels.
Krzysztof, in the previous thread there were several compromises
suggested. Can you re-review those and see if there is a plan that
everyone can get on board with and agree to? If so, then let's make a
priority in getting that implemented for this release. Otherwise, if
there's no consensus position possible, then we should revert the patch
from Cairo trunk and give the discussion more time to percolate.
More information about the cairo