iced
iced copied to clipboard
iced-rs
for large texts, scrolling can be slow and may seg fault
I'm running MacOS 10.15.7 on a MacBook Pro (16-inch, 2019), and compiling with Rust 1.52.0.
I first observed that in my iced application, in a scrollable, where the scrollable content has ~1000 lines, that scrolling continuously caused progressive degradation in responsiveness, and after about 100 seconds, the app seg faulted, with 30 threads running.
How to reproduce this: shown at the bottom.
What is easier to show is that scrolling through a large text degrades as a function of the total text size. This suggests that the complexity of the scrolling algorithm is supoptimal.
This may or may not be the same problem that caused my crash.
Example of slowness. I cloned iced at e292821c3780fc5a57c835815efc7a232ce4dc32, which is dated Tue May 25 16:34:17 2021 +0700. Then I modified iced/examples/scrollable/src/main.rs:
- "Some content that should wrap within the \
- scrollable. Let's output a lot of short words, so \
- that we'll make sure to see how wrapping works \
- with these scrollbars.",
+ vec![include_str!("../../../src/application.rs"); 10].join("")
This change makes the text ~3000 lines long.
With this change, when the scrollable example is run, the response time to an individual scroll operation is several seconds.
How to reproduce the crash
1. git clone https://github.com/10XGenomics/enclone
2. cd enclone
3. git checkout 93969c02871caa6351c870851d6cb049bcdc5a3c
4. cargo b
5. target/debug/scroll_crash
6. push Submit
7. scroll up and down in the scrollable at the bottom, scrolling every second or so for
roughly 100 seconds; it crashes for me
The crash code lives in a crate scroll_crash in the enclone repo. I tried excluding it from the workspace, and compiling it alone. This resulted in much slower scrolling, but no crash. I can't explain this.
I confirm the issue of performance degradation on Win 10 with only 30 lines of (colored) text in scrollable. I haven't experienced segfault, even though I tested scrollable on 25k lines of text -- application was practically unusable in that case.
