If we only ignore the result of the computed boundary intersection,
because the edge is inside that boundary, then we can simply forgo the
calculation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we need to extrapolate the edge to the boundary, then we run the risk
of an overflow for an immaterial result. So if the edge does not cross
the boundary, we can simply use the corresponding end-point and not emit
the boundary segment.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60489
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we evaluate the line first using y-for-x to find the clipped
vertical range and then rasterise the line using x-for-y, we can incur
severe rounding errors that cause us to draw beyond the clipped region.
The first simple attempt at a fix is to tweak the clipped vertical range
such that the evaluated extents of the line are contained.
Reported-by: Taekyun Kim <tkq.kim@samsung.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Trimming the composite extents may result in the clip being
reconstructed, but we the polygon continued to hold a reference into the
freed clip's array of boxes. So if we intend to reuse the polygon limits
after performing the clip we need to refresh them.
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>
The edge clipper is more complicated than it should be and contains a
subtle bug: when an edge is almost horizontal, it is always considered
as having a positive slope.
Explain what should be done and do it in a simpler way.
Fixes horizontal-clip.
Uli Schlachter analysed the error behind the polygon reduction and
discovered that it was due to the clipping of a line which intersects
the clip box (p1, p2) but is range limited by (top, bottom) to be inside
the clip box.
Fixes hatching
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As Andrea Canciani pointed out even if it is horizontal within the clip
box, it may still have vertical extents outside of the clip box for
which we need to project onto the clip boundary in order to maintain
the correct polygon winding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Step 1, fix the failings sighted recently by tracking clip-boxes as an
explicit property of the clipping and of composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
_cairo_polygon_limit() had to be called immediately after
_cairo_polygon_init() (or never at all).
Merging the two calls is a simple way to enforce this rule.
Using _cairo_path_fixed_interpret_flat() greatly simplifies the path
to polygon conversion (because it already converts curve_to's to
line_to's).
This commit also removes the optimization which merges two consecutive
lines if they have the same slope, because it's unlikely (since it
should already happen during path construction), it doesn't provide
better performance (at least not measurable with the currently
available cairo-traces) and bloats the code.
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
The early discard checked if the line was below the last clip-box, or if
above the first. However, the clip-boxes are only sorted on by the bottom
(not the strict XY-banded sort of the regions) and so this was erroneously
discarding lines.
For the simple cases where the clip is an unaligned box (or boxes), apply
the clip directly to the geometry and avoid having to use an intermediate
clip-mask.
We refactor the surface fallbacks to convert full strokes and fills to the
intermediate polygon representation (as opposed to before where we
returned the trapezoidal representation). This allow greater flexibility
to choose how then to rasterize the polygon. Where possible we use the
local spans rasteriser for its increased performance, but still have the
option to use the tessellator instead (for example, with the current
Render protocol which does not yet have a polygon image).
In order to accommodate this, the spans interface is tweaked to accept
whole polygons instead of a path and the tessellator is tweaked for speed.
Performance Impact
==================
...
Still measuring, expecting some severe regressions.
...
Ensure that no assumptions are made that a small allocation will succeed
by manually injecting faults when we may be simply allocating from an
embedded memory pool.
The main advantage in manual fault injection is improved code coverage -
from within the test suite most allocations are handled by the embedded
memory pools.
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.
Enlarge the embedded arrays of edges and points for cairo_polygon_t and
cairo_spline_t respectively, such that the frequent allocations are
eliminated whilst running a firefox3 benchmark.
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.
This patch introduces three macros: _cairo_malloc_ab,
_cairo_malloc_abc, _cairo_malloc_ab_plus_c and replaces various calls
to malloc(a*b), malloc(a*b*c), and malloc(a*b+c) with them. The macros
return NULL if int overflow would occur during the allocation. See
CODING_STYLE for more information.
Now, the functions to add new data to a polygon all become void,
and there's a new _cairo_polygon_status call to query the status
at the end of a sequence of operations.
With this change, we fix many callerswhich were previously not
checking the return values of _cairo_polygon functions by adding
only a single call to _cairo_polygon_status rathern than several
new checks.
This is necessary to avoid many portability problems as cairoint.h includes
config.h. Without a test, we will regress again, hence add it.
The inclusion idiom for cairo now is:
#include "cairoint.h"
#include "cairo-something.h"
#include "cairo-anotherthing-private.h"
#include <some-library.h>
#include <other-library/other-file.h>
Moreover, some standard headers files are included from cairoint.h and need
not be included again.
This patch was produced with the following (GNU) sed script:
sed -i -r -e 's/[ \t]+$//'
run on all *.[ch] files within cairo.
Note that the above script would have also created all the changes
from the previous commits to remove trailing whitespace.
