Make sure to make the GL context is current before destroying the femtovg canvas.
The drop implementation of the canvas will call functions to delete GL resources such as textures, FBOs, etc.
and for that to work reliably the context must be current.
This works like the other implementations, so it will allocate on the heap, format with core::fmt
, have no compile-time switch and not print the location.
It would be nicer to forward to defmt directly, but that means the regular
formatting wouldn't work and defmt needs to be a dependency at the call site.
For more fine-grained debugging it's easier to introduce local defmt usage.
This bundles all the board specific code in the mcu crate. There's much
to do though, so this is just a rough start and when it's all done we
should probably squash this.
Since the mcu crate dependencies require nightly and our CI builds with
stable, this removes the mcu backend from the default build and the ci.
* This requires passing the target through a thread-local (hence the corelib export
* Also fetch the background color and resize the item to match the draw target size
* The draw target is a generic and it just needs to support convertion from rgb888
Because we currently don't have a way to detect when the popup is closed
we workaround the problem by never show the combo box as open.
Workaround #456
It can be activated using the `SIXTYFPS_DEBUG_PERFORMANCE` environment
variable, which takes a comma separated list of options.
This could be extended in the future with different locations for the
overlay (corner_top_left, corner_top_right, etc.) - but this is a simple
start.
cc #728
When called from inside some winit event handler, we'd go straight to
`with_window_target` to get hold of the event proxy and send it. However
when called through some external event handler (DOM), the scoped
CURRENT_WINDOW_TARGET would not be set and MAYBE_LOOP_INSTANCE would
also be empty because `run` takes it. So instead we'd end up creating an
new event loop instance and the event would sit in there forever.
Instead, this change brings WASM in line with the other platforms by
using the dedicated event loop proxy (global_proxy). Because of the lack
of threading the dance of storage for that is a little different though.
On Windows 10, the creation of symlinks by normal users requires
enabling the developer mode, which may or may not be acceptable in
corporate environments with restricted IT setups.
We introduced the symlinks for the shared special key codes mapping,
which instead this patch places into a shared sixtyfps-common crate.
This issue was caused by two bugs:
* The scale factor was not a property dependency of the Image cache entry's property tracker
* The texture cache key for SVGs should include the target size that's scaled to.
Fixes#734
Separate the image cache from the texture cache.
The latter needs additional data in the key. The two have less in common that it seemed.
This also fixes a small issue with `CachedImage::upload_to_gpu` that for
SVGs would return a decoded (rendered) SVG image, instead of a texture.
That was harmless because we always call `ensure_uploaded_to_gpu`
later, but now we assert that the texture cache only holds textures,
because clear() (former remove_textures()) just clears everything.
Share the code that defines the key with a macro over all the backends using
a symlink.
This is a symlink rather than exposing the macro directly since we add this
module in every backend, and each backend re-declares the macro to handle
the part that it needs. This needs to be a symlink because it will also be shared
with the compiler that does not depends on sixtyfps-corelib
The initial clipping was set in physical size rather than in logical size.
When scaling up, this does not have visible effect, but when scaling down
it clips too much.
The cached shadow image should just be the cache of the shadow. This
removes a visible "edge" from the shadow sometimes and brings the
rendering in line with the Qt backend.
... and using the sixtyfps! macro
The problem is that the OUT_DIR in the build script of the macro crate
is reporting a target directory for the host (since the macro itself is
built for the host), but we need to get the OUT_DIR of the crate, so query
it in the macro. Unfortunatelty, that env variable is only set when the
crate (using the macro) has a build script. So use a fallback to find the
target directory
Fixes#462
Due to a bug in Qt's implicit sharing in QPalette, the resolve mask of
QGuiApplicationPrivate::app_pal would get changed with an unrelated setColor
call and thus break color resolution from a new base palette when the theme changes.
