The layout pass needs to see when going over the layout, that these
properties are set. So inline the element that sets these properties if
they are not set in the base.
Fixes#8091
The problem is that the precision of f32 for coordinate wouldn't be
accurate enough with such big viewport to put the elements so that they
are next to eachother.
So put the elements relative to the Flickable instead of relative to the
created moving viewport Rectangle.
Fixes#3700
Note that the ListView still use f32 for the scrollbar value, meaning
that at some point, the wheel stops working as the wheel increment is
smaller than the f32 increment, and scrolling becomes somehow fuzzy.
But this only happens after one more billions pixels now, so one can
have more than 50 millions of elements without much problems
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
```
Last commit uncovered some bug in which the second phase of inlining
tries to inline children in the wrong place
(This usually inlines zero children as it was already done in the first
phase, but we still assert that the location is right)
This reverts commit 66652cdc1d.
The warning in the gallery are hard to fix because the component inherit
from a layout and there is nowhere to place the popups
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"
Semi-random selection of clippy topics that were
uncontroversial before:-).
Leaves about 84 deduplicated issues in the code base
according to clippy from nightly.
This type is poorly implemented and not documented. Let's remove it for now.
It shall remain available in the git history in the event of a resurrection.
When having a binding such as
```
foo <=> bar
```
The default value will always be the value of `bar` regardless what's
the value of foo.
This change of behavior is the only one that makes sense bacause if we
are having repeater or if, this will be a problem. eg:
```
property <xxx> bar;
if (some_cndition) : SomeElement {
foo <=> bar;
}
```
Then we can't possibly take the default value of foo for the value of
bar since it depends on the condition. (and it is even worse in case of
repeater)
This is a change of behevior, this is why the tests have changed. The
cse of tests/cases/bindings/* were already covered by a warning since
0.3.0 so that should be fine. But the warning did not trigger for
builtin property such as `visible` (eg, input/visible_mouse test)
Also some internal two way bindings had to be reversed.
cc: #1394
These are two different concept, and it is confusing to keep them in the
same enum
We want to support component without any base element, and Void is
already used for global component, so do this refactoring before
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/flickable.rs (Browse further)
