If a subsequent PATH_OP is just a continuation of the previous line, i.e.
it has the same gradient, then just replace the end-point of the previous
line with the new point rather than adding a new operation. Surprisingly
this occurs in the wild, but the main motivation is a future optimisation
to reduce the number of intersections during stroke-to-path.
As pointed out by Andrea, and now tested by test/degenerate-curve-to, a
curve-to that begins and ends on the same point may extend further due to
its control points. It can not be simply replaced with a degenerate
line-to. In order to do so we will need more extensive degeneracy
checking, ala _cairo_spline_init().
Handling clip as part of the surface state, as opposed to being part of
the operation state, is cumbersome and a hindrance to providing true proxy
surface support. For example, the clip must be copied from the surface
onto the fallback image, but this was forgotten causing undue hassle in
each backend. Another example is the contortion the meta surface
endures to ensure the clip is correctly recorded. By contrast passing the
clip along with the operation is quite simple and enables us to write
generic handlers for providing surface wrappers. (And in the future, we
should be able to write more esoteric wrappers, e.g. automatic 2x FSAA,
trivially.)
In brief, instead of the surface automatically applying the clip before
calling the backend, the backend can call into a generic helper to apply
clipping. For raster surfaces, clip regions are handled automatically as
part of the composite interface. For vector surfaces, a clip helper is
introduced to replay and callback into an intersect_clip_path() function
as necessary.
Whilst this is not primarily a performance related change (the change
should just move the computation of the clip from the moment it is applied
by the user to the moment it is required by the backend), it is important
to track any potential regression:
ppc:
Speedups
========
image-rgba evolution-20090607-0 1026085.22 0.18% -> 672972.07 0.77%: 1.52x speedup
▌
image-rgba evolution-20090618-0 680579.98 0.12% -> 573237.66 0.16%: 1.19x speedup
▎
image-rgba swfdec-fill-rate-4xaa-0 460296.92 0.36% -> 407464.63 0.42%: 1.13x speedup
▏
image-rgba swfdec-fill-rate-2xaa-0 128431.95 0.47% -> 115051.86 0.42%: 1.12x speedup
▏
Slowdowns
=========
image-rgba firefox-periodic-table-0 56837.61 0.78% -> 66055.17 3.20%: 1.09x slowdown
▏
As we don't strictly use the current-point in comparing paths, exclude it
from the hash. Similarly use the path content flags as a cheap means to
differentiate contents.
Use the cairo_list_t and its style of iterators to improve the readability
of the cairo_path_buf_t management. Note the complications that arise from
the embedding of the initial buf -- however the macros do help make the
unusual manipulations more identifiable.
Whilst constructing the path, if the operations continue to be
axis-aligned lines, allow the is_box and is_region flags to persist. These
are set to false as soon as a curve-to is added, a diagonal or in the case
of is_region a non-integer point.
When cairo_curve_to happens to start a new subpath (e.g., after a call
to cairo_new_sub_path()), it also needs to update the last_move_point.
Otherwise the new current point after a close_path() will be at an
unexpected position.
Therefore, call _cairo_path_fixed_move_to() explicitly.
Adds a new, fake, fontconfig font backend. Fontconfig can be disabled
using --disable-fc, in which case the toy text API wont find fonts and
the internal font will always be used.
Also defines the feature macro CAIRO_HAS_FC_FONT. The two fontconfig-specific
functions in cairo-ft.h depend on that macro now.
We want to hit the current fast paths for rendering axis aligned
rectilinear paths rather than spans, and for that we need to be able
to identify regional paths.
The spline decomposition code allocates and stores points in a temporary
buffer which is immediately consumed by the caller. If the caller supplies
a callback that handles each point computed along the spline, then we can
use the point immediately and avoid the allocation.
A new meta-surface backend for serialising drawing operations to a
CairoScript file. The principal use (as currently envisaged) is to provide
a round-trip testing mechanism for CairoScript - i.e. we can generate
script files for every test in the suite and check that we can replay them
with perfect fidelity. (Obviously this does not provide complete coverage
of CairoScript's syntax, but should give reasonable coverage over the
operators.)
Modify cairo-pdf-operators.c to emit to 're' path operator when the
path contains only a rectangle. This can only be done when the path is
logically equivilent to the the path drawn by the 're'
operator. Otherwise dashed strokes may start on the wrong line.
ie the path must be equivalent to:
cairo_move_to (cr, x, y);
cairo_rel_line_to (cr, width, 0);
cairo_rel_line_to (cr, 0, height);
cairo_rel_line_to (cr, -width, 0);
cairo_close_path (cr);
which is also equivilent to cairo_rectangle().
By enlarging buf_size to ensure the correct alignment of the points
array with the cairo_path_buf_t block, we can efficiently use the
padding bytes to store more ops.
In http://bugs.gentoo.org/show_bug.cgi?id=203282, it was identified that
the cairo_path_buf was causing unaligned accesses (thus generating SIGBUS
on architectures like the SPARC) to its array of points. As we manually
allocate a single block of memory for the cairo_path_buf_t and its
arrays, we must also manually ensure correct alignment - as opposed to
cairo_path_buf_fixed_t for which the compiler automatically aligns the
embedded arrays.
All the copied data buffers except the first one weren't completely
initialized (num_ops and num_points). That was the cause of the failure
of some vector surface tests, like random-intersections.
Allocate subsequent path bufs twice as large as the previous buf,
whilst still embedding a small initial buf into cairo_path_fixed_t
that handles the most frequent usage.
The only caller of cairo_path_fixed_get_current_point(), used the status
return to determine whether or not the path had a current point (and did
not propagate the error) - for which we had already removed the
_cairo_error() markup. Now we reduce the boolean status return to a
cairo_bool_t, with a net reduction in code.
Do not use _cairo_error(CAIRO_STATUS_NO_CURRENT_POINT) within
_cairo_path_fixed_get_current_point() as the only caller,
cairo_get_current_point(), expects and handles that status.
Every time we assign or return a hard-coded error status wrap that value
with a call to _cairo_error(). So the idiom becomes:
status = _cairo_error (CAIRO_STATUS_NO_MEMORY);
or
return _cairo_error (CAIRO_STATUS_INVALID_DASH);
This ensures that a breakpoint placed on _cairo_error() will trigger
immediately cairo detects the error.
