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>
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>
Similar to 1f4d05b55c
'Fix calling '_cairo_spline_intersect' for in-bounds checking of splines'
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
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>
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>
