Our web site and READMEs direct to our Rust API crate, which makes sense as it provides
fundamental traits and types. However as pointed out in
#811 we should advertise the existence of the interpreter API.
Ideally we'd link to the crate documentation that
(1) perfect matches the version number
(2) uses sixtyfps.io for our built docs and docs.rs for the published crates
I could not find a way to do this (not without making the crate a dependency and adding features), so
this patch is a compromise that I've seen used in other
crates.
* Improve headings and linkage
* Replace "you can use XXX to YYY" with "Use XXX to YYY"
* In the limitation about exported components, link to the tracking
issue.
This is listed under the reference ("how to") and explains `SIXTYFPS_SLOW_ANIMATIONS`, SIXTYFPS_DEBUG_PERFORMANCE` as well as `SIXTYFPS_SCALE_FACTOR`.
cc #728
For the MCU port, we need to proccess the image to save them in the binary
in a convenient format.
This patch start this work by trying to anaylyze what format should an image
be using, and saving it as a texture in the binary.
The current graphical backend and the C++ frontend are not yet supported
Avoid creating an intermediate array of items to free the graphics resources.
Instead call run-time function with the item tree as a parameter, which is traversed.
It's practically the same data structure that was previously created, except
that it is shared/global and has little holes for the dynamic tree items, but those are easy to skip.
This is done by exposing the ModelNotify to the caller via the new
ModelTracker trait, which has a function that allows "hooking" into the
dirty tracking of the size.
By extension, this also works in JavaScript.
cc #98
It does not update the version number in the README because
these are either not part of the versionized documentation
or the demantic versioning make it work anyway
This adds an ImageBuffer and PixelBuffer type for SharedVector
backed images. The documentation explains how to use this
with low-level rendering functions and the popular image crate.
Fixes#387
Further build on b3529d1b75 and move the
strong/weak reference dance into the API crate out of the generated
code.
Saves ~21k llvm lines on the printer demo (debug).
It's also possible to move the as_pin_ref() bit, but that didn't
really give any savings overall.
The binding setup functions (set_binding, set_animated_binding, etc.)
are taking the binding basically as an `impl Fn() -> T`, which means
each call site creates a new copy. The bodies of these can be quite big.
Since most of our uses follow the pattern of just capturing the
samereduce the number of copies needed parameter, we can reduce the
number of copies needed by providing wrappers.
With rustc 1.54.0 on my mbp and debug, the build time of
touch ../ui/printerdemo.60
cargo rustc
goes from 1m:15s down to 42s, and total llvm lines goes from
2079842 down to 1134237.
and replace it with the internal, re-exported WindowHandleAccess
one.
Strictly speaking, this is a breaking change. In practice the
returned type of this trait was in `sixtyfps::re_exports`, so any
public use is questionable :)
That's all it is nowadays, it's a wrapper around Rc<Window>. It's not an
alias because we need to also "wrap" it to C++ via cbindgen, but that's
about it.
