Lagging when editing any kind of text
Reported version
3.0
Priority
P1 - High
Type
Performance
Frequency
Many
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
Yes
Workaround
No
Project
Taking too long time responding and sometimes freezing when trying to edit any kind of texts, including system txt, staff txt, lyrics, tempo, etc. Sometimes causes crash when RAM has low free space.
This problem takes place in every single 3.x.x versions. This happens in 3.0.0 (first 3.x build), 3.0.1.5087.06a66a2 (current 3.x release), and 3.0.1.a504e39 (current 3.x DEV release).
Comments
How much ram does your computer have, and how much ram does your resource manager say musescore eats up? And what OS on?
Regarding slow processing of layout, I would just consider that part of #280952: Score Editing Slow if it is a big score. Are you on a big score or small score?
In reply to How much ram does your… by ericfontainejazz
Sorry, supposed to be cpu, not the ram. According to the Task Manager, when idle, musescore takes 1±0.5% cpu and 310MB ram. However, when editing text, ram consumption is same but cpu consumption rises to 32%. (Tested in the dev version just now)
CPU is i5-6200U, RAM is 8GB, and OS is Win10. This is happening in scores of medium(70 bars 6 staffs, no texts except tempo) ~ extra large (1K+ bars 5 staffs, no texts), but this didn't happen in 2.x versions with the same score files. I expected that this can happen in this extra large thing, but not in the medium one.
I can verify this. Basically CPU usage jumps from 1% while idle way up to %50 (of 4-core system) when editing text. I think what happens is MuseScore has to rerender the scoreview on each new keypress.
CPU busy of 32% is a lot for 2 cores and 4 threads
although for comparison, as I'm typing into chromium browser right now, I can watch my chromium browser jump from ~0% idle CPU usage up to %25 (of 4-core system). So i don't think musescore's behavior is totally out of the ordinary. Hypothetically the text-editing code could be cleverly-designed such that typing each letter doesn't trigger a score update, but I think based on current design, that is simply how things are. I'm dropping the severity down one notch, cause I think that it just the way the code is designed at the moment and fixing this would require some more clever score updating routine.
Note I'm on a i7-6500U CPU @ 2.50GHz linux system...seems comparable to yours.
I should note that on a simple text-eidting program (leafpad, comparable to windows notepad), typing text doesn't eat up any cpu at all...but of course leafpad doesn't have to rerender a score on every keypress. On a slightly-more involved editor "AbiWord" (comparable to early MS Word), I still get around %25 usage of my 4-core system CPU when typing.
Funny, lately I've been relying on this full-score-relayout-on-each-edit to help me test some code I've been working on - gives me a nice way to force a relayout without changing the actual notes :-). Used to be Ctrl+A did this but no more.. But I agree, it's not good, seems we should be able to apply the same sort of "partial relayout" (do we have a term for this) for text edit as for any other.
In reply to although for comparison, as… by ericfontainejazz
I think what @ericfontainejazz thinks is right... Maybe we'll need a tweaked sequence on the text editor and score re-rendering. My idea is to change the re-render timings, from every single letter input to exiting text editor by hitting Escape key or mouse clicking outside the text box.
Thanks for sharing your ideas! Maybe I could just wait until a fix comes up later.