Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

for large texts, scrolling can be slow and may seg fault #897

Open
DavidBJaffe opened this issue May 30, 2021 · 4 comments
Open

for large texts, scrolling can be slow and may seg fault #897

DavidBJaffe opened this issue May 30, 2021 · 4 comments

Comments

@DavidBJaffe
Copy link

DavidBJaffe commented May 30, 2021

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.

@DavidBJaffe 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 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 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 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
@hecrj
Copy link
Member

hecrj commented May 31, 2021

This is probably caused by #41.

@hecrj hecrj added the bug Something isn't working label May 31, 2021
@13r0ck
Copy link
Member

13r0ck commented May 31, 2021

#783 is also related

@unreal79
Copy link

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.

@kipnek
Copy link

kipnek commented Sep 6, 2023

anyone have good answers to this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants