Add a testsuite called gsk-compare-vulkan to run
the gsk renderer tests with the Vulkan renderer.
The current stats:
Ok: 184
Expected Fail: 0
Fail: 204
Unexpected Pass: 0
Skipped: 2
Timeout: 0
For now, we mark all the tests as failing to
avoid ci breakage. To run the tests locally,
you can do:
meson test -C_build --suite gsk-compare-vulkan
I have no idea about the UI for this yet, but there's a list of nodes
now that you can click on to get previous ones back.
Ultimately I want to have some way to compare nodes or do transitions,
but so far, this is an experiment.
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.
These are just nice apis to have and avoid having to carry
these around as extra arguments in many places.
This was showing up as inconvenience in writing tests
for the measure apis.
The progress is non-uniform, so simple translation of progress doesn't work.
So check if larger and smaller values inch closer towards minimal distance.
Conics are evil in that their parameter skews towards the center, and if
it's a very flat conic (weight almost equal to 0), then we'd approximate
it with a single segment and not subdivide, which would cause the
parameter to be wildly off around 0.25 or 0.75.
And that would cause offset calculations to fail.
GskCurve is an abstraction for path operations. It's essentially a
collection of vfuncs per GskPathOperation.
GskStandardContour has been ported to use it where appropriate.
A gskpathop is a pointer to a graphene_point_t* with the low bits used
to encode the GskPathOperation. It's an easy way to introduce API for
operations.
So far it's just used to replace GskStandardOperation.
