You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
DavidBJaffe
changed the title
scrolling responsiveness degrades as the total scrollable content size increases
for large texts, scrolling can slow down and sometimes it will seg fault
May 30, 2021
DavidBJaffe
changed the title
for large texts, scrolling can slow down and sometimes it will seg fault
for large texts, scrolling can slow down and sometimes seg fault
May 30, 2021
DavidBJaffe
changed the title
for large texts, scrolling can slow down and sometimes seg fault
for large texts, scrolling can be slow and repeated scrolling may seg fault
May 30, 2021
DavidBJaffe
changed the title
for large texts, scrolling can be slow and repeated scrolling may seg fault
for large texts, scrolling can be slow and may seg fault
May 30, 2021
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.
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
ate292821c3780fc5a57c835815efc7a232ce4dc32
, which is datedTue May 25 16:34:17 2021 +0700
. Then I modifiediced/examples/scrollable/src/main.rs
: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
The crash code lives in a crate
scroll_crash
in theenclone
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.The text was updated successfully, but these errors were encountered: