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
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.
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"
The README.md contains the warning that used to be in lib.rs.
Add README.md files to all internal crates
... pointing to the official public crate to use instead.
Rename internal crates
fixup: README files
fixup rename
