Add a way to find the intersections of two curves.
We can handle some curve-line intersections directly,
the general case is handled via bisecting.
This will be used in stroking and path ops.
This is mainly useful for decomposing a conic into
cubics. The criterion here for terminating the
subdivision is very improvised.
But it also allows for other use cases, such as
raising the degree of quadratics to cubics.
An auxiliary API introduced here is gsk_curve_elevate.
This is to make room in the api for quadratic curves.
In detail:
- Replace GSK_PATH_CURVE by _CUBIC
- Rename gsk_path_builder_curve_to to _cubic_to
- Replace GSK_PATH_FOREACH_ALLOW_CURVE with _CUBIC
- Replace GskCurveCurve with GskCubicCurve
If we can't append a circle contour, just
convert to a standard contour. This warning
was occasionally causing tests to fail
(when a suitable random path gets generated).
When looking for discontinuities, there
is no need to check for epsilons. As we
move close to the end of one contour / the
beginning of the next, the path length distance
between the two points will get arbitrarily
small, so we can just check that the distance
between the points is more than twice that.
This makes spurious failures of the /path/get_point
test go away.
Close reading of sources revealed that we
were not actually using the same conditions
as skia here, causing our measurements to
come out slightly different.
With this change, we are in almost perfect
agreement with skia.
Follow the usual implementation more closely,
and drop reporting a separate 'on_edge' bit.
This was wrong in some cases, and we don't
need it. See the testcase in this commit
for a case where 'on_edge' was wrongly
deciding that a point is inside.
It turns out that using strchr() to identify
chars in your string isn't safe since strchr
happily matches the '\0' at the end of the input.
If we are not careful, that makes use walk
off the end of the string.
This issue was found by asan.
g_test_init sabotages tests in release builds,
we have to use (g_test_init) to avoid the sabotage.
At the same time, we have to avoid using g_assert,
since that's a no-op in release builds.
The IFUNC resolvers that we are using here get
run early, before asan had a chance to set up its
plumbing, and therefore things go badly if they
are compiled with asan. Turning it off makes things
work again.
The gcc bug tracking this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110442
When curves have long straight parts that decompose into a single line,
don't try to split them. Instead, split at a well-known position and a
the part of that long straight line as a line.
This gives way more accurate numbers and is more accurate than 1% for
everything but contours with very small weight and
start_point == end_point, where the error is closer to 1.5%.
When decomposing curves that are too straight, we may emit lines for
long parts of the curve. These lines do not properly map
t => distance
and it is better to treat them as a regular line than a curve.
This reason argument gives that information.
No users so far, that will happen in followup commits.
This is a regular path creation API, so treat it that way.
On top, it is rather awkward if the only constructor for a path that is
immediately visible to people reading the docs is the one that takes a
Cairo path - when we want to deprecate Cairo.
