Extreme slowdown in continuous view, depending on number 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)

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.

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…

Better, indeed. With this score, attached in my first comment ( 3Haydn_Symphony Andante Finale.mscz), the pitch change with arrow up/down reacts well, promptly.

While with the 3.1 beta, the same action is slowed down by something.

An updated build, slightly more optimized:

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

At this point I'm less worried about how well it does the job - it does what it does, not as fast as page view, but still better. What I'm more concerned about is if it breaks anything - any times when an edit to a score in continuous view causes a glitch (likely in the display of some elements in subsequent measures), a crash, etc.

"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.

Yes, there is a problem (minor severity),
but why would a person want to move a Trill one or two measure forward (or backward)?

Update: Sorry: Yes, Musescore users do these things often (as I often see in the Forum) :) // no sarcasm

Thanks for catching this! Working on a fix.

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.

Fixed in branch master, commit ddbb5c1266

fix #286882: apply layout range to continuous view + collect_artifacts

Automatically closed -- issue fixed for 2 weeks with no activity.