The interface of the various buffer/image_diff functions is improved to
provide the maximum pixel difference in addition to the number of pixels
that differ. This value can then be used to compare against a per-backend
tolerance.
Currently I've set the SVG backend's tolerance to 1 to handle some issues
we're currently seeing of single-bit differences on different systems, (but
we're not exactly sure why yet).
Also I improved the image_diff routines to properly report a status value
on failure rather than the bogus value of -1 for pixels_changed.
Basically, it's evil to write a loop like:
while ((c -= 4) > 0) {
...
}
for one reason that doesn't work if c is unsigned. And when c is signed, if
for some reason c is about -MAXINT, then it will overflow and not work as
expected.
It's much safer (and more gcc warning friendly) to rewrite it as:
unsigned int c;
while (c >= 4) {
...
c -= 4;
}
Behdad chased this bug down when looking into bug #7593. This
bug is what finally motivated us to figure out how to get -Wextra
(for the "always true" comparisons of unsigned variables against
negative values).
We'd been wanting some of the warnings in -Wextra for a long time,
but we had failed in tryingto squelch some of the undesired warnings.
We finally figured out how to do this correctly by simply ordering
the warnings correctly.
The documentation for GetGlyphOutline() states that outline returned is grid
fitted and if an application requires an unmodified outline it can request an
outline for a font whose size is equal to the font's em unit.
This seems to suggest that the solution to this bug would be to obtain the
unmodified outline data and scale it to the required size.
https://bugs.freedesktop.org/show_bug.cgi?id=7603
The setting of current point to (0,0) is actually harmless, but it
definitely looks like a bug, (since after close_path the current point
is really the last move point).
We don't keep track of last move point here, nor do we even need to.
So we can be consistent with _cairo_path_fixed_close_path by not
adjusting current point at all, (the subsequent move_to coming right
behind the close_path will fix up the current point).
