summaryrefslogtreecommitdiff
path: root/src/cairo-path-stroke-traps.c
Commit message (Collapse)AuthorAgeFilesLines
* Round joins fix (spline_cusp_tolerance)Christian Rohlfs2022-12-281-10/+22
| | | | https://gitlab.freedesktop.org/cairo/cairo/-/issues/520
* Fix cast between incompatible function types warningsAdrian Johnson2021-08-221-1/+9
| | | | warning: cast between incompatible function types from ‘cairo_status_t (*)(void *, const cairo_point_t *)’ {aka ‘enum _cairo_status (*)(void *, const struct _cairo_point *)’} to ‘cairo_status_t (*)(void *, const cairo_point_t *, const cairo_slope_t *)’ {aka ‘enum _cairo_status (*)(void *, const struct _cairo_point *, const struct _cairo_slope *)’} [-Wcast-function-type]
* build: Fix various compiler warningsGeorge Matsumura2020-11-071-2/+1
| | | | | | This fixes a few compiler warnings that were encountered with gcc 9.3.0. Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
* Revert "stroker: Check for scaling overflow in computing half line widths"Uli Schlachter2017-05-131-1/+0
| | | | | This reverts commit 91b25005d62fe4ca178f45d349374e42c29a5e11 because it causes lots of new crashes due to assertion failures.
* stroker: Check for scaling overflow in computing half line widthsChris Wilson2017-05-041-0/+1
| | | | | | | | | | | | | | | Given a combination of a large scaling matrix and a large line, we can easily generate a half line width that is unrepresentable in our 24.8 fixed-point. This leads to spurious errors later, such as generating negative height boxes, and so asking pixman to fill to infinity. To avoid this, we can check for overflow in calculating the half line with, though we still lack adequate range checking on the final stroke path. References: https://bugs.webkit.org/show_bug.cgi?id=16793 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: magomez@igalia.com Tested-by: Bryce Harrington <bryce@osg.samsung.com> Acked-by: Bryce Harrington <bryce@osg.samsung.com>
* win32: Fix compilation of 'cairo-path-stroke-traps.c' with MSVC8Hans Breuer2014-11-201-4/+6
| | | | | | | "The issue here is that Visual Studio 2005+ is quite strict on type conversions (so it wants code to be clear enough on conversions)." Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=84908
* stroke,traps: Emit join without loss of precisionChris Wilson2014-09-291-15/+40
| | | | | | | | | | | | | | As the target renderers operate at a different sample resolution then we use internally for coordinate representation, there is always a potential for discrepancies in the line gradients when passing around trapezoids. To overcome this, the protocol specification of trapezoids uses the full lines and vertical range as opposed to vertices and so long as we always use the same lines for conjoint trapezoids, they remain abutting in the rasteriser. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84115 Testcase: bug-84115 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* Fixes stroke-clipped, i.c. of a dashed strokeegag2013-10-311-1/+1
| | | | | | | Similar to 1f4d05b55c96347aa4240190fda27f951b00c539 'Fix calling '_cairo_spline_intersect' for in-bounds checking of splines' Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
* stroke: Flip the dev slope as well for computing the cusp on a degeneracyChris Wilson2013-01-091-0/+2
| | | | | | | Otherwise, the join think it starts and end in exactly the same direction and elimiates the round capping. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* stroke: Make the incremental trapezoid stroker optionally available againChris Wilson2013-01-031-0/+1120
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>
View Lorry Controller Status