Use the font matrix found in the FcPattern to
transform the quads we use to render the glyphs.
This makes Cantarell Italic come out just like
it does with freetype.
When the font appears to be synthetic bold (as
indicated by th embolden property in FcPattern),
use glyphys boldness uniform to render the font
bolder.
Use path ops to simplify the path we get from
harfbuzz, since variable fonts often have overlapping
contours, and the glyphy shader can't handle those.
This copied more or less what the coloring vertex shader
was doing in that we premultiply alpha. That changes how
we apply alpha in the fragment shader to match.
This fixes a white halo around the fonts.
This adds a new texture library that can upload SDF data
from libglyphy into regions of a texture atlas so that it
can be accessed by Glyphy shaders in the appropriate place
and format.
Some of the placement positioning may seem odd in that it
needs to follow a certain format to be decoded from the
Glyphy shaders.
If the text node has color glyphs, then we need to dispatch
to the legacy form of rendering which uses FreeType/Cairo/etc
to upload glyphs to a rendered glyph cache.
Otherwise, we can dispatch to a new function which will
eventually use Glyphy to shape to SDF content and upload
to an alternate texture atlas.
We will implement stroking by filling the stroke path.
Compute the stroke path ahead of time, so we don't have
to do it over and over.
This may change in the future, at least for simple
strokes, so keep this private.
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.
Add a function that takes a path, and offsets it
by some distance, applying line-join parameters
as needed. The implementation is reusing the
infrastructure of the stroker.
Implement stroking for paths.
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.
There are special-case implementations for rectangle
and circle contours, since in many cases the outlines
of these contours just consist of two of the same
shapes.
These tests check that gsk_curve_intersect finds
the intersections we want and get_bounds returns
proper bounding boxes.
We also check a few simple cases of offset curves.
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.
Add getters for bounding boxes of curves.
We have cheap ones, which are just the bounding
box of the control points, and tighter ones, which
require finding the actual extrema.
Bounding boxes are needed to implement intersection
via bisecting.
Take a rendernode as source and a GskPath and GskStroke,
and fill the area that is covered when stroking the path
with the given stroke parameters, like cairo_stroke() would.
