Linear Layout Performance
- Dominant language
- Rust
- Stars
- 4.8k
- Forks
- 270
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 2
Description
This is an issue relating to poor performance that occurs when having certain layout setups. Not entirely sure that this is a result of linear layout but it is a common denominator, and so the title of the issue should be changed if a different cause is more accurate.
# Problem description
Code Example: https://gist.github.com/MinusGix/64c3fedd3a71f45bbd7eef906d8d26fe
This is a very stripped down version of a chat application I'm writing, the example just adding lorem ipsum text 45 times.
Running this with release mode (`cargo run --release`) results in barely usable delay when scrolling and when simply typing in the textarea.
Removing the `TextArea` (or replacing it with a `TextView` with some text) leads to no delay (while still keeping the vertical `LinearLayout`).
Replacing the `TextArea` with an `EditView` leads to the same delay.
Removing the user *and* `LinearLayout` in the `add_message` function (resulting in just doing `chat_area.add_child(TextView::new(text));` leads to no delay, but keeping the LinearLayout and removing the user so there is only the text within the horizontal linear layout leads to the delays.
# Environment
* Operating system: Manjaro (Arch Linux) using i3.
* Backend used: ncurses 6.2
* Current locale:
```
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=
```
* Cursive version: Crates.io 0.15.0 and latest git version (on main branch)
* Terminals: VSCode integrated terminal, termite, xterm
# Note
Not entirely sure as to why this occurs. I'd presume its doing expensive relayouting of the large amount of text when it is unneeded, but I do not know the code base that well.
If you have suggestions for alternate ways of structuring it, I am open to those, but this seemed like the simplest way of getting the format that I desired.
Contributor guide
Assessment
This issue has not been assessed yet.