Whilst it cannot handle self-intersecting strokes (which includes the
antialias region of neighbouring lines and joints), it is about 3x
faster to use than the more robust algorithm. As some backends delegate
the rendering, the quality may still be preserved and so they should be
responsible for choosing the appropriate method for generation of the
stroke geometry.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In 545f3085.. the cairo_spline_add_point_func_t type was modified to
accept the tangent in the point, but cairo-rectangle.c was not updated
accordingly.
Fixes:
cairo-rectangle.c: In function '_cairo_box_add_curve_to':
cairo-rectangle.c:297:11: warning: passing argument 1 of
'_cairo_spline_bound' from incompatible pointer type
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This allows us to actually clip out the geometry before we record it, as
suggested by allowing the user to supply an extents... But it will be
advantageous in later patches for reducing the amount of work we need to
perform to replay.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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
This is a more useful definition that is able to individually track the
rectangles that compose the composite operation. This will be used by
the specialist compositors as a means to perform the common extents
determination for an operation.
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.
Based on feedback from Jeff Muizelaar, there is a case for a very quick
and dirty extents approximation based solely on the curve control points
(for example when computing the clip intersect rectangle of a path) and
by moving the stroke extension into a core function we can clean up the
interface for all users, and centralise the logic of approximating the
stroke extents.
When analysing the stroke extents, we need the original fixed-point
extents so that we do not incur an OBO when we round-to-integer a second
time. We also need a more accurate estimate than simply using the control
points of the curve, so pass in tolerance and decompose until someone
discovers a cheaper algorithm to determine the precise aligned bounding
box of a bezier curve.
A cairo_composite_rectangles_t contains the coordinates of rectangular
windows into each of the source pattern, mask, clip and destination
surface containing the pixels that will combine in a compositing
operation. The idea is to have a uniform way to represent all the
translations involved rather than overloading parameters like src_x/y,
dst_x/y, etc., sometimes with different incompatible meanings across
functions.
Adrian Johnson discovered cases where we mistakenly compared the result
of unsigned arithmetic where we need signed quantities. Look for similar
cases in the users of cairo_rectangle_int_t.
Make sure that we don't test lines that start or end inside the box,
since our algorithm will find intersections on the wrong ends on the
line, and not count them.
This rectangle has regular integer values, not fixed-point values.
So the old name was horribly wrong and misleading, (and yes I think
it was even I that had suggested it).
