We're currently using three different versions of ttf_parser, and
this brings it down to 2. The other culprit is femtovg.
Saves ~1kb on release build of sixtyfps-wasm-interpreter
Rendering tests/cases/examples/rectangle_clip.60 shows a border radius
for the clipped area that's not identical with the border radius of the
inner edge of the rectangle stroke.
It appears that the stroke's inner radius is not exactly the difference
of the line (border) width but rather scaled by kappa.
Fix issue in
https://github.com/sixtyfpsui/sixtyfps/issues/207#issuecomment-825780094
For the purpose of alignment, we need to use the font height, not the actual
text height, because otherwise it does not look visualy centered if the
text does not have letters that goes under the baseline
When rendering into a layer, we applied the y coordinate system flip
using a transform. That transform is incompatible with
Canvas::fill/stroke_text, which uses transform_point to transform the
glyph quads. That appears to not work, as opposed to the
y-flip in the main vertex shader.
Fortunately we can work around it by doing the flip when rendering the
layer image (as part of the fill).
Closes#199
As the type of the Value wouldn't match the expected type
Fixes#173
(Also added a way to test the interpreter by making the interpreter
make sure the property "test", if it exists, is true)
According to llvm-lines, MaybeAnimatedPropertyInfoWrapper::set_binding was
in the top 5 of functions with 15971 lines over 46 copies.
Split the code that does not depend on the Item parameter in a different function
As reported in issue #176 , there is a difference between the rendering
with Qt and femtovg. It appears that this is due to incorrect
assumptions about whether the rgb values in the intermediate buffer
image for colorization have the alpha-channel pre-multiplied or not.
When rendering into the image buffer, we would pre-multiply the alpha,
but when rendering the buffer itself, femtovg's fragment shader would
assume texture type 2 and multiply the alpha again. Therefore set the
image flag to avoid that.
This removes the need to manually register fonts. This is initially
applied to the printer demo, but the other demos and removal of the
public manual registration API will come in follow-up commits.
Use font-kit's get_fallback_fonts on Windows, since it's actually implemented there.
This allows determining the fonts to fall back to given the reference text.
Fixes#195
For rendering itself as well as font_metrics() queries, store the result
in the item's rendering cache. This will be needed as the lookup is
about to become more expensive due to the need of calling OS functions
that do text analysis to determine a list of fallback fonts.
When text hasn't changed but we re-render items or re-do the layout, we
need that to be cached.
Pass everything needed for delayed evaluation for
`PlatformWindow::font_metrics()` to permit caching the font matching
result in the Text/TextInput's rendering cache.
We query text metrics frequently for text items, for example when in
layouts. This requires font resolution, which is about to become more
much more expensive due to analysis of the underlying text. To speed
this up, the objective is to use the item rendering cache. Making that
work in turn requires querying all related properties inside a property
tracker. That means we need to delay querying anything related to that,
including the font request needed for the `font_metrics()` function on
the PlatformWindow trait.
