| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one is for interactive exploring of svg paths.
You can enter an SVG path in the entry and hit Enter
to see how GSK renders it. If you click the button
in the headerbar, you can see what GTK thinks the
closest point, tangent and distance are wrt. to the
mouse position, and the bounding box of the path.
There's also stroke parameters to play with.
|
|
|
|
| |
It comes in handy, and does no harm.
|
|
|
|
| |
Add a simple demo for editing a poly-Bezier curve.
|
|
|
|
|
| |
Implement offsetting of paths by reusing the
infrastructure of the stroker.
|
|
|
|
|
|
|
|
|
| |
Add a function that takes a path, and offsets it
by some distance, applying line-join parameters
as needed.
This commit just adds the api, the implementation
will be in the following commit.
|
|
|
|
| |
Move some utility functions around.
|
|
|
|
| |
Implement arced joins as specified in SVG2.
|
|
|
|
| |
Implementation will follow.
|
|
|
|
| |
Fix winding numbers, and strokes wrt to direction.
|
|
|
|
|
|
| |
Check that the outlines of random paths look as
expected. We currently have to exclude paths where
points get too close to each other.
|
|
|
|
|
|
| |
Add tests to check that any point on a path is
always at most half the line-width away from the
stroke path with that line-width.
|
|
|
|
|
|
|
|
|
|
|
| |
Implement gsk_contour_default_add_stroke, which takes a contour
and stroke parameters, and adds contours to a path builder for
the outline that woul be produced by stroking the path with these
parameters.
The current implementation does not try to handle short segments
in the vicinity of sharp joins in any special way, so there can
be some artifacts in that situation.
|
|
|
|
| |
The outline of a circle is just two circles.
|
|
|
|
|
| |
In many cases, the outline of a rectangle is just
two rectangles.
|
|
|
|
|
|
| |
Add the plumbing that will let us do special-case stroking
for rectangles, circles and other special contours. There
is no implementation yet.
|
|
|
|
| |
This will be used in the stroker.
|
|
|
|
| |
Its easy but thats no reason not to have this api.
|
|
|
|
|
| |
The stroker relies on offsetting.
This only tests a few very simple cases.
|
|
|
|
| |
The stroker relies on this working.
|
|
|
|
| |
The stroker relies on these to work.
|
|
|
|
|
|
|
|
| |
Nothing prevents control points from being identical,
and if that happens, some of our constructions involving
tangents and normals break down. Handle these cases in
get_{start,end}_tangent and offset, for the case of
cubics.
|
|
|
|
| |
This will be used in stroking.
|
|
|
|
|
|
|
| |
This method creates an offset curve from an existing
curve by just moving the control points laterally.
This will be used in stroking.
|
|
|
|
| |
We don't have good error bounds here, unfortunately.
|
| |
|
|
|
|
|
|
| |
This is mainly useful for decomposing a conic into
cubics. The criterion here for terminating the
subdivision is very improvised.
|
|
|
|
| |
All curve types are equally fast here.
|
|
|
|
|
| |
This shows how much more expensive curve
intersections are.
|
| |
|
|
|
|
|
| |
This tests horizontal line/conic intersection,
which failed before the fix in the previous commit.
|
|
|
|
|
|
|
|
| |
graphene_rect_intersect returns FALSE when you
intersect the bounding boxes of axis-aligned
lines, so we never find intersections with those.
Make things better by making the bounding boxes worse.
|
|
|
|
|
| |
These tests check that gsk_curve_intersect finds
the intersections we want.
|
|
|
|
|
| |
Add a way to find the intersections of two curves.
This will be used in stroking.
|
|
|
|
| |
Add getters for bounding boxes of curves.
|
|
|
|
| |
The rest just give us no end of numeric trouble.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test takes a lottie file and a timestamp in seconds and produces a
rendernode at that timestamp.
It then serializes that node and compares it via diff(1) with a file
containing the expected output.
This is a lot stricter than it needs to be (because different node files
can generate the same output and updates to the rendering pipeline can
break everything) but I chose this method on purpose because it does a
good job at guarding against accidental changes in other parts of the
code.
It's also better than comparing image output because it avoids
antialiasing artifacts when using curves and things like that.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Supports:
* Taking a screenie:
ottie image file.lottie image.png
* Recording a rendernode:
ottie node file.lottie render.node
* Encoding an image:
ottie video file.lottie video.webm
|
| |
|
| |
|
|
|
|
|
| |
Allow start >= end to mean that the path continues at the beginning
after reaching the end until it reaches the point at @end.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
A relatively cheap way to get bounds for the area
that would be affected by stroking a path.
|
| |
|
| |
|