With jemalloc the page size is a compile time constant that results in
the process aborting on memory allocation if the compile time determined
page size does not match the kernel reported page size at run-time.
When we, or our users, compile the above programs for aarch64-linux,
there is a fair expectation that the resulting binary works on any
aarch64-linux system. As we can't determine the target page size
reliably, disable jemalloc.
Fixes#8134
Commit cd6f2e2 reformated the .toml, but the 80 char width column is
judged too small to be practical
Add a .taplo.toml file
Also do not split feature array
... using taplo with default settings
I tried this with 4 spaces indentation, but the patch is almost as
big as this one, so I went with default settings instead as that
is just easier:-)
We decided that the compatibility with people having enabled the extra
format in image 0.24 [1] is not worth it compared to the extra compilation
time most people gets by default when they don't need this feature.
(Which is less than 10% slower when the feature is enabled)
Since then there is no need for compat-1-10, remove it
[1] by depending directly on image 0.24 in their Cargo.toml and enabling
the features, which will not work with Slint 1.10 that now use image 0.25
Extract the `from_json` and `to_json` code from the viewer into the `interpreter`.
Extend the `from_json` and `to_json` a bit. Add some simple tests while at it.
* optimize: use jemalloc for slint-viewer
The lots of allocations are slowing down slint-viewer.
By using the faster jemalloc, we get a significant time boost
on Linux at least, where I can observe a 15% time reduction:
Before:
```
Time (mean ± σ): 936.6 ms ± 13.5 ms [User: 688.8 ms, System: 191.1 ms]
Range (min … max): 918.9 ms … 955.6 ms 10 runs
```
After:
```
Time (mean ± σ): 794.8 ms ± 16.2 ms [User: 645.4 ms, System: 99.2 ms]
Range (min … max): 755.0 ms … 810.7 ms 10 runs
```
* optimize: also use jemalloc for slint-compiler
As with the slint-viewer, we can observe a drastic time improvement
of around 13% when using jemalloc for slint-compiler:
Before:
```
Time (mean ± σ): 772.8 ms ± 9.2 ms [User: 633.5 ms, System: 136.5 ms]
Range (min … max): 763.3 ms … 787.8 ms 10 runs
```
After:
```
Time (mean ± σ): 672.5 ms ± 13.5 ms [User: 610.4 ms, System: 60.1 ms]
Range (min … max): 655.1 ms … 700.7 ms 10 runs
```
* optimize: also use jemalloc for slint-lsp
The impact here was not measured, but it should be in a similar
ballpark to the slint-compiler and slint-viewer, and thus quite
noticeable in practice.
Added image-default-formats with all the format supported by image by
default, and enable that feature by default.
Also put that feature in compat-1-2 for compatibility with user that
have used image 0.24 with enabled features.
Make a new compat-1-10 feature that does not enable default format by
default
ChangeLog: upgraded image crate to 0.25, added a new cargo feature
to enable all image formats. (that feature is enabled by default with
compat-1-2, added compat-1-10 to disable it
Fixes https://github.com/slint-ui/slint/issues/7251
This makes copying such types much cheaper and will allow us to
intern common struct types in the future too. This further
drops the sample cost for langtype.rs from ~6.6% down to 4.0%.
We are now also able to share/intern common struct types.
Before:
```
Time (mean ± σ): 1.073 s ± 0.021 s [User: 0.759 s, System: 0.215 s]
Range (min … max): 1.034 s … 1.105 s 10 runs
allocations: 3074261
```
After:
```
Time (mean ± σ): 1.034 s ± 0.026 s [User: 0.733 s, System: 0.201 s]
Range (min … max): 1.000 s … 1.078 s 10 runs
allocations: 2917476
```
This removes a lot of allocations and speeds up the compiler step
a bit. Sadly, this patch is very invasive as it touches a lot of
files. That said, each individual hunk is pretty trivial.
For a non-trivial real-world example, the impact is significant,
we get rid of ~29% of all allocations and improve the runtime by
about 4.8% (measured until the viewer loop would start).
Before:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 664.2 ms ± 6.7 ms [User: 589.2 ms, System: 74.0 ms]
Range (min … max): 659.0 ms … 682.4 ms 10 runs
allocations: 4886888
temporary allocations: 857508
```
After:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 639.5 ms ± 17.8 ms [User: 556.9 ms, System: 76.2 ms]
Range (min … max): 621.4 ms … 666.5 ms 10 runs
allocations: 3544318
temporary allocations: 495685
```
This assumes any string value for an image property is a path. This
could be expanded in the future to support loading raw pixel values by
e.g. parsing a data URI.
ChangeLog: viewer: `--save-data`/`--load-data`: support for images with paths (#6169)
Closes#6169.
For example, running the viewer with a DISPLAY wrongly set:
Before the patch:
```
thread 'main' panicked at tools/viewer/main.rs:123:32:
called `Result::unwrap()` on an `Err` value: Other("Could not initialize backend.\nError from Winit backend: Error initializing winit event loop: the requested operation is not supported by Winit\nError from LinuxKMS backend: Timeout while waiting to activate session\nNo backends configured.")
stack backtrace:
[...]
```
If just using `?` instead of `.unwrap()`:
```
Error: Other("Could not initialize backend.\nError from Winit backend: Error initializing winit event loop: the requested operation is not supported by Winit\nError from LinuxKMS backend: Timeout while waiting to activate session\nNo backends configured.")
```
If using an wrapper that uses Display for Debug
```
Error: Could not initialize backend.
Error from Winit backend: Error initializing winit event loop: the requested operation is not supported by Winit
Error from LinuxKMS backend: Timeout while waiting to activate session
No backends configured.
```
Some editors, such as vim, rename (move) a file to a backup location,
then write the new contents to a new location when the user saves
their changes. notify stops watching the renamed file, and does not
automatically start watching the new file created. Additionally,
slint-viewer attempts to reload before the editor has written the new
file, which causes an error. The file is then never reloaded because
the watcher was lost.
This patch solves the problem by attempting to watch the file again,
if the previous watch failed due to a Generic or PathNotFound error.
Generic is required because this is error type we get on macOS for "No
such file or directory.". We delay the retry by a small timeout to
give the editor a chance to write the new file. Note that this still
results in an error being printed about the missing file.
Tested manually by editing both root .slint file, and .slint files
imported from sub-directories.
Closes: #3641
Updated the version from 1.1 to 1.2
Renamed the header to "Slint Royalty-free Desktop, Mobile, and Web Applications License"
Added definition of "Mobile Application" and grant of right
Moved "Limitations" to 3rd section and "License Conditions - Attributions" to 2nd section
Added flexibility to choose between showing "MadeWithSlint" as a dialog/splash screen or on a public webpage
Moved the para on copyright notices to section under "Limitations"
Note: this could be a breaking change if someone did
```
image = { version = "0.24", features = [...] }
```
To enable more features decoder of the image to support more file format
in slint
The trick is that the backend selector build by default with the
i-slint-backend-qt, but the "enable" feature is only enabled if the
qt-backend feature is enabled explicitly, or on linux from the slint
or slint-interpreter crate
... and use it to hide internal functionality so users will notice that
they depend on fucntionality we do not provide any guarantees for.
Make the lsp and viewer request the internal feature when building the
interpreter.
This moves most of the version information we need to update into one
place.
Note that the workplace dependency features are in *addition* to any
feature set when using the workspace dependency. So we have all
workspace dependencies defined with `no-default-features = true`.
This doesn't require a windowing system, just Linux and Vulkan drivers
that supports the display extensions.
It's called linuxkms as soon this will go beyond Vulkan and also support
EGL and perhaps dumb buffers for software rendering.
