SmolStr has an Arc internally for large strings. This allows
cheap copies of large strings, but we lose that ability
when we convert the SmolStr to a &str and then reconstruct a
SmolStr from that slice.
I was hoping for some larger gains here, considering the impact
of this code change, but it only removes ~50k allocations,
while the impact on the runtime is not noticeable at all.
Still, I believe this is the right thing to do.
Before:
```
allocations: 2338981
Time (mean ± σ): 988.3 ms ± 17.9 ms [User: 690.2 ms, System: 206.4 ms]
Range (min … max): 956.4 ms … 1016.3 ms 10 runs
```
After:
```
allocations: 2287723
Time (mean ± σ): 989.8 ms ± 23.2 ms [User: 699.2 ms, System: 197.6 ms]
Range (min … max): 945.3 ms … 1021.4 ms 10 runs
```
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
```
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 ensure_window and popupwindow passes were looking up the "Window"
builtin in the global register instead of in the builtin register,
causing the presence of an user-defined "Window" to cause panic.
The "Clip" and "BoxShadow" calls are not affected because they were
looking up in the builtin reguister, but using the appropriate function
is more future-proof
Fix#3916
commit 975abf3c42 introduced a regression.
Two problem:
- we were taking the geometry from the parent instead of the element
that need the shadow
- Element::make_rc override the geometry with its own properties
Unfortunately annot be tested as this only visual, and the software
renderer don't support shadow yet
Fixes#3743
Parents surch as Opacity, Clip, and co, used to steal the x and y
property of their children, making the property not what they ought to
be.
Now that we refactored recently the code so that geometry need not to be
always linked to a property of the same name, we can dissociate the x
and y property of these generated elements and their content so that the
actual "x" property of the former elementstay some value, despite its
relative item property is now 0.
Had to change a bit of code that was still assuming a literal "height"
or "width" or "y" or "x" property that no longer worked when the
geometry is dissociated from its property
Fix#1072
Make sure this is the actual builtin type we are looking at and not a
re-defined component
Doesn't work for ListView unfortunately because ListView is not a
builtin type
CC #861
Move "internal" crates into the `internal` directory. This first batch
includes most of sixtyfps_runtime but leaves the rendering backends
alone for now.
pre-commit applied some cleanups to the moved files:
- Consistent newline at end of file policy
- trimming trailing whitespace
- Formatting Cargo.toml files.
2022-01-31 16:00:50 +01:00
Renamed from sixtyfps_compiler/passes/lower_shadows.rs (Browse further)