gyscos / gyscos/cursive

Linear Layout Performance

Open
#530 1 comment 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.