Some arcs may not result in any content, for example if the radius is too small
or start and end pointer overlap. Let Lyon do the
checking for us and handle it accordingly.
Newer versions of Lyon will allow the re-use of the SvgArc created temporarily.
Instead of trying to convert the individual (future) elements, let's use a builder.
This way the markup remains simple and due to
future support for bindings we can't really
pre-compute the path events anyway.
This comes with a factory function that re-directs to the backend and a
run member function to replace
sixtyfps_runtime_run_component_with_gl_renderer. For now it's all still
hidden in the generated run() method.
This is relatively straight-forward via a pass in the compiler to
collect the resources to embed and then use include_bytes! (once per
resource).
What's really annoying is that the rust resource enum can't store a
&'static [u8] because cbindgen doesn't represent that, probably because
the slice representation isn't guaranteed to stay as it is. So instead
this, for now, uses raw pointers.
The Image's source property used to be a string. Now it is a Resource
enum, which can either be None or an absolute file path to the image on
disk. This also replaces the internal Image type.
The compiler internally resolves the img bang expression to a resource
reference, which shall remain just an absolute path. For now the target
generator passes that through, but in the future the target generator
may choose a target specific way of embedding the data and thus
generating a different Resource type in the final code (through
compile_expression in the cpp and rust generator).
The C++ binding is a bit messy as cbindgen doesn't really support
exporting enums that can be constructed on the C++ side. So instead we
use cbindgen to merely export the type internally and only use the tag
from it then. The public API is then a custom Resource type that is
meant to be binary compatible.
Based on Olivier's suggestion, the text rendering primitive is created
by painting the text onto a temporary HTML canvas
element and binding that to a texture.
This shall become the successor to RenderingInfo. For now it's just a
place holder, but the idea is that backend creates the opaque primitive
that holds this public rendering primitive, exposed via the
HasRenderingPrimitive trait.
Rename the backend specific RenderingPrimitive to LowLevelRenderingPrimitive,
in order to make room for a high-level RenderingPrimitive enum that's public.
In order to support multiple font sizes, etc. we have to deal with the
fact that the glyphs for a string may not end up all in the same atlas
texture. Therefore splitting of glyph runs by texture is necessary.
This works but could be improved further by sharing the vertex arrays
and just re-binding to a different texture and drawing the run's
triangles by index.
Forward the text and color properties to the rendering backend, where
right now we just rendering all the glyphs into a dedicated texture.
Next steps are a glyph atlas texture, blending the specified color with
the alpha of the glyphs, configurable size and family, shaping with
Harfbuzz and may more things.
