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.
This moves a lot of the texture atlas control out of the driver and into
the various texture libraries through their base GskGLTextureLibrary class.
Additionally, this gives more control to libraries on allocating which can
be necessary for some tooling such as future Glyphy integration.
As part of this, the 1x1 pixel initialization is moved to the Glyph library
which is the only place where it is actually needed.
The compact vfunc now is responsible for compaction and it allows for us
to iterate the atlas hashtable a single time instead of twice as we were
doing previously.
The init_atlas vfunc is used to do per-library initialization such as
adding a 1x1 pixel in the Glyph cache used for coloring lines.
The allocate vfunc purely allocates but does no upload. This can be useful
for situations where a library wants to reuse the allocator from the
base class but does not want to actually insert a key/value entry. The
glyph library uses this for it's 1x1 pixel.
In the future, we will also likely want to decouple the rectangle packing
implementation from the atlas structure, or at least move it into a union
so that we do not allocate unused memory for alternate allocators.
This removes the sharing of atlases across various texture libraries. Doing
so is necessary so that atlases can have different semantics for how they
allocate within the texture as well as potentially allowing for different
formats of texture data.
For example, in the future we might store non-pixel data in the textures
such as Glyphy or even keep glyphs with color content separate from glyphs
which do not and can use alpha channel only.
This allows the gskglprograms.defs a bit more control over how a shader
will get generated and if it needs to combine sources. Currently, none of
the built-in shaders do that, but upcoming shaders which come from external
libraries will need the ability to inject additional sources in-between
layers.
If the max_entry_size is zero, then assume we can add anything to the
atlas. This allows for situations where we might be uploading an arc list
to the atlas instead of pixel data for GPU font rendering.
This was getting some simple polygon cases wrong :(
The problem here is a misunderstanding in line_get_crossing.
It was returning 'on edge' when a point of the polygon is
on the ray, which is not what 'on edge' is about.
Add some test cases involving horizontal edges that coincide
with the test point.
For collinear line segments, return up to 2 intersections
for the endpoints of the intersection (which is also a
line segment in this case).
Tests included.
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.
