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
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
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.
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