Our demos use some symbols such as the back arrow and the ugly style
uses a down arrow for the combo box. These symbols are not in Roboto and
also not in the default font font_kit gives us on macOS.
Therefore for WASM we switch over to DejaVu, which is bigger than
Roboto.
For macOS this patch implements rudimentary fallback list generation
using CTFontCopyDefaultCascadeListForLanguages. This needs further work
to respect the locale and correctly translate styles - eventually this
should go into font-kit.
A general aspect with the font fallback handling is that femtovg doesn't
support on-demand loading yet. Instead it uses owned_ttf_parser, so
every font will be read entirely off disk. That's why for macOS we trim
the list. We could perhaps do the analysis ourselves.
Linux and Windows are to follow.
Separate GLFont from GLFontMetrics, the latter being as light as keeping
primarily the request around (and canvas), the former holding the list
of font resolution.
* Fix passing the correct source clip rect (width and height were missing)
* Adjust to nanovg's image rendering model where the image is basically
a patter underneath the path rendered. So for a sub-image
we need to offset the image pattern and scale the pattern and the path.
Constrain the border width by the rectangle to avoid that the border
would cancel itself out when too big.
This fixes most of the checkbox rendering in the slide puzzle.
Represent a non-specified pixel size and font weight through a None option.
This is cleaner and has the added benefit that the backend can now
easily decide what the default size/weight should be.
For the GL backend a resolved font is just a handle (femtovg::FontId)
and we can cache that. Consequently we don't really need Rc<dyn Font>
but can let `fn font(...)` on the backend return a "resolved" font that
includes the pixel size, which in turn simplifies the Font trait
signatures.
The only caveat is that because on the item level we don't know what the
chosen backend type is, we can only receive a `dyn Font`, which means
it's wrapped - for now - in a Box.
Use a save/restore state pattern for the entire renderer instead of passing around clip rectangles as data structure.
That's less data copying and maps naturally to existing mechanisms,
which in turn can use their own dirty handling to make
save_state/restore_state as cheap as possible.
Re-apply the caching mechanism from the old renderer
that keeps weak references and drains them after frame rendering.
This fixes switching between the themes in the slide puzzle.
Create the font request on the text item side to reduce duplication and
remove the fallback logic from the font_weight accessor, in preparation
for automatic generation of that getter.
* When calculating the height of text for vertical alignment purposes,
don't use the minimum height but stick to ascent + descent - like the old
renderer. This gives Text items a constant height that depends on the
font size and not the content.
* Avoid scaling text metrics twice. It turns out that femtovg uses the
device pixel ratio / dpi argument for `set_size` only for scaling text
metrics. Since we do all the mapping from logical pixels to physical pixels
it's correct to let femto only operate in physical pixel range. As a bonus
this allows removing the refresh_window_scale_factor() dance in the
backend (including making the context current, etc.)
In the previous renderer the text, by default, is drawn at the top of the
bounding box. The default femtovg alignment is more like QPainter, but
that's not quite what we want here.
Ensure the dpi on the canvas is up-to-date before/after rendering, as
measure_text etc. rely on it and it's otherwise initialized to 1 by
default. Unfortunately this requires jumping through some hoops, but
that can be fixed later in the canvas.
This means going back to an immutable renderer reference and interior
mutability for the canvas and the gpu cache. This is because while
traversing the item tree for rendering we may end up destroying
other items due to the lazyness of the models.
... to a more general gpu_cache and store an enum. That way we can
encapsulate the resource releasing - in the future - entirely in the
backend through run-time polymorphism in the backend (gpu cache data
enum) instead of a vtable method in the item to destruct the correct
type of data.
