The objective is to automatically create a propery cmake module, with a
FindSixtyFPSConfig.cmake, corresponding targets .cmake files, etc. This
should encapsulate the build profile (debug vs. release) and also allow
making the choice of shared vs. static transparent.
Unfortunately it does not seem to be possible to easily combine different
crates into one cdylib crate that can re-export symbols from the
statically linked rust crates (cbindgen generated, as well as manual
extern "C").
That means for the dynamic case (not cared for right now), we're going
to need to create either one cdylib per crate that has public symbols or
manually re-export the symbols.
For the static case, linking just against the "last crate" in the chain
(the gl renderer backend) is sufficient to pull in all needed symbols.
In addition for the static case we need to specify the linkage of some
external libraries. This can be extracted manually via
cargo rustc -p gl -- --print=native-static-libs
for example. For now that's in the changed CMakeLists.txt, but the plan
going forward is to automate this extraction in an xtask, to paste that
into the cmake target.
Finally, both linkage scenarios require access to the headers. This is
for now solved by generating them simply in an include sub-directory of
the build folder ($root/target/${profile}/include).
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.
Make our GL context not current when done with the initialization
and make it current for the duration fo primitive creation and frame
rendering.
Fixes#4
