This issue is not quite specific to the gallery, a simpler test case is
this:
```
App := Window {
preferred-width: 500px;
preferred-height: 750px;
HorizontalLayout {
Rectangle {
background: blue;
}
}
}
```
As there is no fixed width/height set, the size is calculated by layout and
apply_window_properties() sets the inner size correctly on the winit window.
However the width/height properties on the root Window item are not set, remain
zero and thus lead to incorrect rendering. They are not set because they are
identical with what window.inner_size() reports - we assume no change and that
they are in sync.
The bug however is in the creation phase, when we decide on an initial size to
pass to the window_builder, we should also set those on the root item. This is
where window.inner_size() and the root item's width/height get out of sync.
Properly release GL resource when unmapping a window and detect stale
cache indices using a generation count. This fixes the disappearing
images (GL textures would be invalid and need to be re-created) as well
as the panics when an item's cache index ended up being re-used because
some other item was drawn first and allocated that indices. The latter
is fixed by using a generational counter on the cache that's bumped when
clearing, instead of a single "cache_ok" bool.
Move the item graphics cache into the GraphicsWindow and then, together
with the new femtovg::TextContext, we can provide the metrics and can
stop using the window_map_pending notifier for this query.
With wasm there is no current context (can alwasy render) but we own the
winit::Window. With glutin own the ContextWrapper and have to make it
current (and resize). This patch hides all that behind the OpenGLContext
type.
This is primarly search & replace for now, slightly simplifying function
signatures.
However this paves the way to a thread-local font cache that can share
fonts across windows (not glyph atlas) and also measure without a canvas.
When we calculate the initial layout without a mapped window early on,
we end up with zero text metrics with the GL backend due to an API
limitation of femtovg.
While working on that, this patch introduces a workaround to mark the callers of
image_size() and font_metrics() as dirty when the window is mapped.
Let's keep source compatibility and define `drop-shadow-blur` to be a radius.
The CSS spec says that the standard deviation is half of the radius.
We just need to scale again and increase the shadow rect to make sure that no borders are visible.
Commit bb7b301b10 pulled in a branch of femtovg, which
had a change to its shader that used a variable in the loop condition.
That is unfortunately not supported in WebGL 1.0 / GLES 2.0.
The pinned femtovg works around that limitation.
Fixes#230
This replaces the box gradient with a new implementation that
behaves like the HTML Canvas element, by applying a gaussian
blur to the alpha of the rectangle to shadow.
The drop-shadow-blur property is changed to be now just a "level", like
the HTML Canvas shadowBlur property, which is defined to be half of the
standard deviation of the gaussian blur to be applied.
We don't need a property reference anymore, a plain image reference is fine AFAICS.
Dirtyness of the source is tracked on the caller side of layouting_info()
or in the draw_image_impl anyway.
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
