_cairo_path_fixed_last_op() contains an assertion, which gcc doesn't
like to inline. Since it is a static function, which basically
accesses a value, gcc will inline it anyway when assertions are
disabled, so remove the "inline" hint to reduce gcc warning noise when
doing debug builds.
Fixes:
cairo-path-fixed.c: In function '_cairo_path_fixed_drop_line_to':
cairo-path-fixed.c:373:1: warning: inlining failed in call to
'_cairo_path_fixed_last_op.isra.5.part.6': call is unlikely and code
size would grow [-Winline]
cairo-path-fixed.c:400:1: warning: called from here [-Winline]
...
The plan was "path: Skip calls to zero-length memcpy". However, this skipped
calls if the buffer was still empty, which means that it skipped all calls.
Fixes: Half the test suite, lots of assertion failures
Signed-off-by: Uli Schlachter <psychon@znc.in>
We attempt to copy 0 points onto the array of path points for a
close-path. This is pointless and an unnecessary function call under
MSVC at least.
Based on a patch by Steve Snyder, incorporating Behdad's review
comments.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37836
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
In step 1 of speeding up stroking, we introduce contours as a means for
tracking the connected edges around the stroke. By keeping track of
these chains, we can analyse the edges as we proceed and eliminate
redundant vertices speeding up rasterisation.
Coincidentally fixes line-width-tolerance (looks like a combination of
using spline tangent vectors and tolerance).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since we discard empty fill boxes whilst filling, we can also treat
horizontal/vertical lines as a filled box and so proceed with the
rectangular fast path in the presence of
cairo_rectangle (x, y, w, h)
with w == 0 || h == 0.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
__cairo_path_fixed_is_rectangle() is used by the PS and PDF backends
to check if a path is equivalent to a rectangle when stroking. This is
different from being a rectangle when filling, because of the implicit
close_path appended to every subpath when filling.
Fixes stroke-open-box.
See https://bugs.freedesktop.org/show_bug.cgi?id=34560
gcc complains that:
cairo-path-fixed.c:400: warning: inlining failed in call to
'_cairo_path_fixed_drop_line_to': call is unlikely and code size
would grow
Path are always interpreted in forward direction, so the ability of
interpreting in the opposite direction (which is very unlikely to be
useful at all) can be removed.
The additional time spent in the computation of tight extents for the
curve_to operation doesn't seem to be significant, but it makes the
extents computations faster and the approximations more accurate.
current_point and last_move_to were previously left in their old
position (which could lead to incorrect flag computation if other
operations were added to the path) and flags were not updated.
Only fill_maybe_region can change its value because the transformation
preserves vertical and horizontal lines, but can move the points and
make them integer if they were not or non-integer if they were.
Recomputing it is just as easy as checking if all the points are
integer and the path is fill_is_rectilinear.
Only fill_maybe_region can change its value because the transformation
preserves vertical and horizontal lines, but can move the points and
make them integer if they were not or non-integer if they were.
Recomputing it is just as easy as checking if all the points are
integer and the path is fill_is_rectilinear.
Instead of explicitly calling _cairo_fixed_move_to, setting the
needs_move_to flags is sufficient because the current_point is already
updeted correctly.
Clean up the code and make sure that _cairo_path_fixed_translate is
used whenever the _cairo_fixed_to_double rounding would result in the
matrix being approximated with a translation.
Now move_to's are actually added to the path when followed by a
drawing operation (line_to, curve_to or close_path).
This is implemented by updating the current_point and setting the
needs_move_to when a move_to operation is requested.
Whenever a drawing operation is requested and the needs_move_to flag
is set, a move_to is added before the drawing operation.
When a degenerate line_to is followed by a curve_to operation, the
line_to can be safely dropped, just like for degenerate line_to
followed by line_to.
The low-level line_to optimizations can be implemented in a more
abstract way using _cairo_path_fixed_penultimate_point and
_cairo_path_fixed_drop_line_to.
Instead of explicitly computing the flag in close_path, manually close
the path with a line_to, then drop the last operation if it is a
line_to (it might be another operation if the line_to was ignored
because it would have been degenerate).
Add a function to get the penultimate point and another one to drop
the last operation (assuming it is a line_to).
This allows some more abstraction in the line_to and close_path code.
Flags for the same path can be different depending on its "history"
(in particular if it was constructed and transformed they might be
different from what they would be if each point was transformed and
then the path constructed).
Make the hash independent of buf bucketing, extents and flags.
This makes the hash depend only on the actual content of the path, not
on how it is stored or on any computed property.
Remove _cairo_path_fixed_is_equal and use _cairo_path_fixed_equal
instead.
The latter function can recognize that two paths are equal even if the
drawing commands have been partitioned in a different way in the buf
list.
Instead of simply doubling the buffer size every time we overflow a point
or an op, enlarge the buffer to fit twice the number of used points and
ops. We expect paths to be fairly consistent in the mix of operations,
and this allows the buffer size to tune itself to actual usage and reduce
wastage.
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
Frequently we only need the coarse path bounds, so avoid walking over
the list of points once more as we can cheaply track the extents during
construction.
Bug 26010 - cairo_line_to optimizes away path segments
http://bugs.freedesktop.org/show_bug.cgi?id=26010
As exercised by path-stroke-twice, we incorrectly optimise away a line
segment if the path doubled back upon itself. This is very reminiscent
of the optimisation bug for replacing curve-to with line-to.
Only the very first line-to following a move-to can have any
significance if degenerate whilst stroking, so skip all others.
In other words,
0 0 m 0 0 l stroke
produces a capped degenerate path (i.e a dot),
0 0 m 0 0 l 0 0 l stroke
produces the same degenerate stroke, and
0 0 m 0 0 l 1 0 l stroke
produce a horizontal line.
Malte Nuhn reported hitting an assertion:
cairo-path-stroke.c:1816: _cairo_rectilinear_stroker_line_to: Assertion `a->x == b->x || a->y == b->y' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=24797
when stroking an apparently simple path:
0 8.626485 m
0 8.626485 l
5.208333 2.5 l
10.416667 2.5 l
15.625 2.5 l
20.833333 2.5 l
26.041667 2.5 l
31.25 2.5 l
36.458333 2.5 l
41.666667 2.5 l
46.875 2.5 l
52.083333 2.5 l
57.291667 2.5 l
62.5 2.5 l
67.708333 2.5 l
72.916667 2.5 l
78.125 2.5 l
83.333333 2.5 l
88.541667 2.5 l
93.75 2.5 l
98.958333 2.5 l
104.166667 2.5 l
109.375 2.5 l
114.583333 2.5 l
119.791667 2.5 l
125 2.5 l
stroke
which upon reduction becomes:
0.000000 8.625000 m 5.207031 2.500000 l 125.000000 2.500000 l stroke
The bug is that after spotting a repeated line-to we move the previous
end-point without reclassifying the path, hence we miss the
non-rectilinear step.
To correctly handle retessellating trapezods constructed from alternately
wound boxes, then we need to pass that information from the path to the
tessellator. We do this by switching the direction of the box if the first
edge is horizontal as opposed to vertical.
_cairo_path_fixed_is_box() is only called for filled paths and so must
handle the implicit close (which was already being correctly handled by
_cairo_path_fixed_iter_is_box).
