Extreme slowdown in continuous view, depending on number of beamed notes

• Mar 29, 2019 - 00:15
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
PR created
Regression
No
Workaround
No
Project

Discussion for this starts at https://musescore.org/en/node/285741#comment-903935

When large scores created in version 2.3.2 are opened in version 3.0.5 the response time difference can be extreme.

Using the score at

https://musescore.com/user/6105546/scores/5435811

as an example.

When I opened this score in 2.3.2 and changed a note the response was immediate. In version 3.0.5, when I changed the same note in the same manner (ctrl+alt+up arrow) the response was so slow I thought I had pressed the wrong buttons at first. According to Marc S.'s reply the difference is about 400%.


Comments

Title Extreme slowdown in continuous view Extreme slowdown in continuous view dependant the amount of beamed notes

This Haydn's piece has the particularity of containing many beamed notes (16ths and 8ths, in the two hidden staves included) particularly in the Allegro, but also in the Finale. That's why it's so slow (eg when pitch change of any note) - or depending on the space/layout it occupies as well?

Only these two movements: 3Haydn_Symphony Andante Finale.mscz

Crime of the lese-majesty, sorry: by replacing these notes with half notes and dotted quarter notes, the phenomenon does not happen again: 2Haydn_Symphony Andante Finale half note.mscz

  • From scratch, it can be reproduced. The test file: a file of 8 instruments and 300 measures. The test: select any note and change the pitch with up or down arrow.

At one extreme: all in whole notes: no need to worry about slowness: test whole notes.mscz

At the other extreme, or almost: everything in 64th, and on a single and incomplete system. Not only does the score almost no longer respond to the pitch change, but it is impossible to input the entire first system/staff (I went painfully up to 124 measures, out of 300)

See: test 64th.mscz

And there are all the variants of the in-between: you can see that this is also very slow with two systems containing 16ths: test 16th two systems.mscz

And so on, you can check with the other test files:
test eighth two systems.mscz
test eighth notes four systems.mscz

  • And so, by taking the first extreme case of the 64ths, and exporting to MusicXML format, you can see that with the 2.3.2, in continuous view, there is no problem: the pitch change is done quickly, as expected: test 64th.mxl
    (don't forget to toggle in Continuous view)
Title Extreme slowdown in continuous view dependant the amount of beamed notes Extreme slowdown in continuous view, depending on number of beamed notes

@cadiz1, WOW! That was a lot of work in such a short amount of time. Perhaps the programmers can take this knowledge and make continuous view useful for scores with lots of beams.

Priority P1 - High

Thanks, this is excellent information indeed!

As I worked on some layout issues with beaming recently, I noticed a few inefficiencies in the beam code. One of the main ones is that the nature of getting this things right requires all beamed notes to be laid out twice - once to help us decide on some basics, and then again to settle on final details. So immediately, beamed notes take twice as long as unbeamed notes. However, this was also the case in 2.x as far as I recall, so there is doubtless more to it.

In theory, one change I made recently may help in some case - invisible staves were being fully laid out (thus leading to them affecting spacing inappropriately). In master, this is no longer true.

Anyhow, definitely this gives us something to look at. I still feel, though, that the real opportunity for improvement will come when we find a way to not lay out the entire score on every change.

Status active PR created

Here is a PR that should help: https://github.com/musescore/MuseScore/pull/5013

It works by only laying out the measures that have changed, pretty much like we do in page view. It's a bit more complicated, because for page view, we still lay out the full system containing the changed measures, but in continuous view, the whole score is one long system, and that's what was killing us. So I am trying to be careful to lay out only what is needed within the one long system. it seems to work, but I won't be at all surprised if something has fallen through the cracks. So I'd appreciate help testing. For anyone experiencing this problem on Windows, here is a build:

https://ci.appveyor.com/api/buildjobs/0geqeeq6u3c2ihwc/artifacts/MuseSc…

"any times when an edit to a score in continuous view causes a glitch"

There are X ways to edit a score: you mean with what type(s) of steps? And from scratch or with the previous attachment (Haydn Symphony)?

Good question! If something is going go wrong, it could happen on any edit to any score, really, but in particular, the things I'd be concerned about are changes in one measure that have an effect on subsequent measures somehow. So, anything you do that makes a measure wider or narrower; inserting or deleting a measure or frame; changing key or time signature, etc. Chances are if something goes wrong, it would be obvious, like a whole bunch of notes drawn on top of each other, autoplace working not at all or else sending elements flying way too high, etc.

I'd expect it would be more likely to see problems with scores that have lots of things that I didn't test. I tried to test tremolo, cross-measure barlines, multiple voices, slurs, cross-staff notation - things that have been problematic in the past. But who knows what I missed.

So basically, just load up some "interesting" scores and start doing things to it in continuous view. There's nothing I expect to go wrong, but I also wouldn't be surprised if some particular type of element gets laid out incorrectly or causes other problems. So after some edits, just look at the subsequent measures to see if everything looks OK.

The last problem I fixed in this PR, for example, had to do with beams in measure that contain trills or accent marks (articulations wider that the note itself). If you made any edit in a previous measure that changed it's width, the beam in the measure with the trill or accent would shift slightly, so it appeared disconnected from the stems. That's the sort of glitch I won't be surprised to find more of.

Indeed, I see this glitch. By dragging two or three "tr" articulations, in a very exaggerated way, of course, or via offset X in the Inspector (at least the trill here, I haven't tried anything else yet), it creates space in one or more previous measures. And by continuing in this way, the stems and beams end up being unhappy with that.
We can correct by cancelling or resetting, but of course, it's an unexpected and annoying display.

Video_2019-05-13_161117.gif

Here is a fixed build for Windows:

https://ci.appveyor.com/api/buildjobs/hd6a5scw6l3ivapv/artifacts/MuseSc…

I continue to welcome real-world (or even not-so-real-world) tests to see if you can uncover other glitches! Articulations are definitely one area, beams another, and maybe barline changes - these are some of the places where I have special casing going on. Playback is another area I haven't really explored as I much as I should. The problems some people report where playback starts somewhere other than where they actually clicked - I could easily imagine that happening here. Or places where tempo changes, dynamic changes, repeats, or other things that change the flow of playback end up applying incorrectly.