Slow rectangular selection in continuous view

• Mar 11, 2019 - 08:11

Rectangular selection becomes very slow on large scores when in continuous view. If I switch to page view, it works fine.

It only happens when the starting point is not in view (when instrument names, clef and time signature are rendered in blue color).

I'm using MuseScore 3.0.4.

Comments

• Mar 12, 2019 - 18:26

You should submit an official bug report at https://musescore.org/en/node/add/project_issue?pid=1236. Please include a sample score with exact instructions to see this difference you are talking about. The issue will then be where programmers look for issues to fix.

I'll be honest, at the moment, continuous view issues are a lower priority at the moment, but that should change once page view works well. Perhaps the slow issue for continuous view will prove to be a simple 2 lines of code like the slow page view problem was.

Reply

• Mar 13, 2019 - 14:51

I've been working in Page view since the release of version 3.0.4 and it is FAST! I have a score with 599 measures and 14 instruments and I noticed it getting a little slower at around 500-550 measures. I was close enough to finishing the transcription I decided to tough it out, and it was not too bad. There was only a slight noticeable delay when I entered the last note.

As a contrast, I have a score I've been working on in continuous view and it gets unbearably slow at about 30-50 measures. The response time is very noticeable and almost unbearable already. Needless to say, I'll start working on it in page view now.

There is obviously something slowing down continuous view. It's probably something similar to what was slowing down versions 3.0.3 and earlier.

Reply

• Mar 13, 2019 - 15:27

If I understand correctly, it is because MuseScore now only lays out the systems that are changed by an edit. In page view, it is only a fraction of the score and thus fast. In continuous view, it is the whole score (since the whole score is a single system in continuous view) and thus it is slow. Discussions are ongoing about how to handle the problem. Suggestions are things like to only layout the visible portion of the view. That should fix the continuous view problem and make page view faster too.

Reply

• Mar 13, 2019 - 15:57

I would layout everything from the measure before any visible measure to the measure after what's visible to allow for a smoother scroll left or right. beams and harpins that disappear to the left or right are less likely to be dramatically reshaped when the previous or next measure becomes visible.

As quick as speed becomes a problem, there is more going on than the fact that the entire system is being redrawn. The problem arises with very few measures in the score at all. I'll do a test with a fresh score and get back to this later.

Reply

• Mar 13, 2019 - 16:26

In version 2, I used continuous view to enter scores with about 150 measures and 45 instruments with some noticeable slowdown. Currently (as of 3.0.3) I can only enter about 30 measures before continuous view becomes unsable because there is about a second of delay between entering a note and it stop sounding. As I said, I'll test this later today and report back to assure I'm giving good current (3.0.5) info.

Reply

• Mar 15, 2019 - 16:45

Pini di Roma part I.mscz

Sometime while adding notes from the last page of the score, 9 measures, the delay between note input and display is so bad, I would normally start a new score based upon the same instruments and use copy and paste to move the notes to this score.

My computer has
Processor AMD A6-3600 APU with radeon(tm) HD Graphics 2.10 GHz
Installed RAM 6GB
System type 64-bit operating system, x64-based processor

As I previously said, when I've entered comparable scores in version 2.3.2 using continuous view, I could easily get over 100 measures and would get about the same results as I have now at about 150 measures.

Another unrelated note. Without making a custom page size of 27 feet (slight exaggeration) it is not possible to enter the score in page view and the display really sucks in continuous view, as many others have pointed out.

Reply

• Mar 15, 2019 - 18:25

I did a test, how long to enter a string of sixteenths to cover the last 9 measures just holding the "C" key down on my keyboard. It took 14 seconds to enter 36 notes, or just under 0.4 seconds per note. On the slow side indeed.

This score was created in 3.0 so I can't do a direct comparison. However, I exported to MusicXML, and imported the result into 2.3.2 and did the same test. It took 10 seconds, or just under 0.3 seconds per note. Also n the slow side. Is that extra 0.1 second really the issue, or am I missing something?

I repeated the test by importing the MusicXML into 3.0.5 to be sure it was apples-to-apples, and got the same results.

In this case, the slowdown was 40%; the score I tested earlier was 20%. This is significant indeed, but I guess some of the posts I have seen seemed to be implying something a lot worse. Eg, saying performance at 50 measures in 3.0 is on par with performance at 150 measures in 2.3.2 implies a slowdown of 200%. That estimate is off by an order of magnitude as far as I can tell.

Anyhow, I have no doubt that with some effort, we could apply the same only-update-what-is-needed approach to make continuous view faster, and I do hope someone undertakes that effort.

BTW, can you explain what you mean by " the display really sucks in continuous view"? Are you referring to glitch where drag-select is slow? Or the fact that we choose not to automatically add extra space between staves?

Reply

• Mar 15, 2019 - 18:39

Look at the score in continuous view and notice how everything is run together. That sucks. If there were any realistic way to enter a symphonic score in page view I would do it. I haven't formatted the page for the final view yet, because I don't know what will be necessary by the time I finish the movement. And I never use drag select. I always use click the shift+click to make large selections.

Reply

• Mar 15, 2019 - 19:10

By "run together" you mean what I said earlier - the lack of extra space being added automatically? To be clear, 2.3.2 did not do this either, so this is more a general issue than a 3.0 specific one?

Not sure what you mean about it not being realistic to enter in pageview, I do most of my large ensemble work this way. I use continuous mostly for piano or small ensemble music where the multiple systems per page otherwise get distracting, FWIW.

Reply

• Mar 15, 2019 - 20:12

I did the same test as Marc, filling 9 measures by sixteenths.
On my laptop (which is quite new), it consistently requires 10 seconds, either at end of score, or start.
Then I wanted to do the same test in 2.3.2, but export as .musicxml gives a file that I can't open in 2.3.2
Fatal error: line 44 column 19 Element credit is missing child element.
Trying to open anyway gives an empty score.

Attachment Size
Pini di Roma part I.musicxml 2.46 MB

Reply

• Mar 15, 2019 - 22:37

Your test is flawed. You assume that 20% slow means that if you add 20% more measures to the faster score you will get the same results as the slow score. That's wrong.

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

When I look at this in continuous view in 2.3.2 I get immediate response to change a note. When I open it in 3.0.5 and answer Yes to the load question the delay is so long I thought I hit the wrong key when I changed the note.

Reply

• Mar 15, 2019 - 23:06

Well, the 20% number applied to that specific score, and 40% applied to the other specific score. Those numbers aren't flawed, they are actual measurements of those actual scores and we're meant to be used to play "what if" games - they were just meant to say, how much slower is MuseScore 3 than MsueScore 2 on the same score. Those numbers were accurate for those scores, and they are consistent with that I have seen in other scores.

However, this new score you have posted is indeed different. It isn't just 20-40% slower, it really is slower by a factor of 5 or so (400%) in continuous view. I've never seen anything like that before and am not sure what makes it unique. This would then be a good one to use in future benchmarking, so thanks for the pointer!

Reply

• Mar 16, 2019 - 00:05

All I did was enter the notes the way I always do. This is longer than most scores I work in as far a measures are concerned, but a small percentage (about 1/5) in the number of instruments. I was actually able to enter it as one score rather than resorting to putting together several smaller scores. It also has few dynamics and almost no (possibly exactly 0) hairpins, which have a way of slowing down both versions.

This is the number 1 problem I have using version 3. I couldn't enter a score like

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

into version 3, because entering it in page view is unrealistic and entering it in continuous view is impossible.

Reply

• Mar 16, 2019 - 02:24

Can you explain what you find "unrealistic" about page view? To me it would be far preferable, not just for performance reasons but also so you can be dealing with the actual layout from the beginning.

Anyhow, I loaded the New World score into 3.0.5 and 2.3.2 and did the same comparison, this one came out in between the two extremes - worse than 40% but nowhere near 400%. Even so, the overall performance, while certain sluggish, is nothing like "impossible". Obviously much depends on the speed of your machine, though.

Like I said, it will be good if we can eventually do incremental layout for continuous view as we do for page. Meanwhile, though, I'm still not understanding why you are reluctant to use page view. To me it's the no-brainer solution, really preferable in practically every way I can think of.

Reply

• Mar 16, 2019 - 02:40

The reason I can't use page view is the scaling would have to make the score microscopic and/or the paper huge and then zoom to the point I could see a couple of measures on the screen at a time. This isn't good for entering the score. There are still instruments I haven't encountered in the score, so I haven't added them yet. I still don't know how I would have to set up a page. Setting it up in continuous view is preferable. It worked well in version 2 and is the method I prefer, but can't do in version 3. So version 2 is currently the the best option for entering a score, which is what I will switch to now that this test is done.

Reply

• Mar 16, 2019 - 03:20

What's wrong with just setting a very large large paper size during note ? You wouldn't have to zoom, you see roughly the same number of measures as continuous view. I tried A0 and everything works as expected for me, and very fast. If you need more instruments, add them. If that causes you to need a larger page, increase it. I'm not trying to be difficult but I honestly don't understand the problem with using page view.

Reply

• Mar 16, 2019 - 05:32

Perhaps you missed the several times where I explicitly said I was in favor of improving it. if so, let me repeat again, I totally support the idea of applying the same improvements sort of improvements continuous view that are already applied to page view. I think it's a marvelous idea for someone who has the time and inclination to work on this.

As for why it exists, it's the same as anything in open source software - it exists because someone at some time thought it worthwhile enough to implement. To me, the main use case is piano music or music for small ensembles that are able to fit multiples systems per page. In these types of scores, page view results in distracting line breaks that force you to constantly jump from right to left while working. This is a non-issue for scores for larger ensembles that fit only one system per page. Which is why I am having trouble understanding the resistance to using it here.

Once again I'd be perfectly happy to see someone volunteer their time to improve continuous view. I'd also be very happy to see people create scores like this in MuseScore 3, and I see absolutely no reason this cannot be done using page view.

Reply

• Mar 16, 2019 - 16:48

@Marc

What the about the following proposal:

-Add an option to Page view to auto adjust the paper height to the system height. It could even be simpler than that: without doing any computation this flag could just provide paper with a (virtually) huge height and force the test checking if there is place enough for a second system on the page to always return false.

Why?

Because with this flag turned on, page view would offer the "raison d'être" you have described for continuous view: "avoid line breaks that force you to constantly jump from right to left while working".
But being page view it would enjoy the current speed of page view without needing to fix continuous view. In fact continuous view would then be decommissioned, replaced by this flag.

Reply

• Mar 16, 2019 - 18:00

So, still keep the current width? It's not a bad idea, but it also takes all of a few seconds to set up an appropriate page height yourself in page settings, so I'm not really seeing it being that big a win. Sure, you might have to revisit periodically if you add or remove staves, but how often does that happen, really? Especially once a score gets big enough that you are concerned about performance? Hmm, you'd also want to turn off hide empty staves to keep a more consistent system height, although continuous view effectively disables already.

In any case, I don't think it would completely replace the desire for continuous view, there would still be potential advantages like not having system breaks at all (waste of screen space), having the panel with staffname/clef/key/meter always visible, etc.

But sure, it could have some value. There's already been requests we automatically scale staff size to fit a full system on the page. Tricky in that it might then be different page to page and you could get in an endless loop of adjusting staff size to fit, finding that moves a measure to a different system, readjusting staff size then as a result of a change this has due to hide empty staves or autoplace, etc. But definitely worth further discussin, feel free to start a new thread!

Reply

• Mar 17, 2019 - 19:53

I suppose. I think I'm still missing something really fundamental here, though. If you've already figured out the desired "true" page height, what possible incentive is there to deviate from it? I thought the whole point is that people didn't want to have to figure out the true height until they were all done adding instruments which might not be until they finish the score? If you know the true height, then just use it. Although personally, I like the idea of deliberately working with a somewhat larger page size during note input, so you fit more measures per system. And it takes all of a few seconds to change to the actual page size when done.

So yeah, I feel like I am somehow missing something about what the supposed problems with using page view are. I wish someone could explain simply, step by step, what they are doing, at which step page view presents some sort of problem.

Reply

• Mar 17, 2019 - 19:59

Now ... I'm confused.
How can you say
"I am somehow missing something about what the supposed problems with using page view are"
while you have perfectly explained it yourself 2 posts before:
"distracting line breaks that force you to constantly jump from right to left while working"

Reply

• Mar 17, 2019 - 23:51

Oh, yes, that problem I understand, but it only applies to solo or small ensemble score,s not the sort of large ensemble scores being discussed here. So that's the context I assumed you were talking about. For piano scores, I'd just go to continuous view and call it good; the score would have to be quite long before you saw any slowdown. But sure, I guess a setting a short page height would be a reasonable workaround if the score does get long, and again, seems absolutely trivial to do so and then set back to Letter or A4 or whatever when done.

Reply

• Mar 18, 2019 - 09:34

Wouldn't that just move the problem into page view too? I thought the problem was that there are no system breaks in continuous view and that causes the whole score past the point the change happened to be relayouted? If you then make a huge page without system breaks, wouldn't the same happen? Or will there still be page breaks, so you can at least sometimes get the benefit of incremental layout?

Reply

• Mar 13, 2019 - 16:47

2.x works much faster in continuous view.

I don't think this specific issue is due to automatic layouting, as it's slow even when only making a selection.

I think it's partly caused by the rendering of the blue overlays. Try switching a large score into continuous view and:
1) move so you can see the beginning of staffs. Press Shift + LMB drag to make a rectangular selection. Performance should be good.
2) then move only slightly to the right, so that the beginning of staffs appear in blue, and try to make rectangular selection. Now, it'll be very slow and unresponsive.

Reply

• Mar 13, 2019 - 17:38

My plan is to give a gauge for the programmers to use for understanding what a "Large" program is. When the size gets to a certain point, my computer slows down to the point it is very obvious. This point is a fraction of the measures it was in version 2. I haven't tested it much in version 3.0.4 and later using continuous view, so I can't be sure just using the program is that much slower than it was in version 2.

The hope is that this testing will tell the programmers where they might look to find the slow down.

Reply

• Mar 13, 2019 - 18:25

I don't understand why layout in continuous view doesn't just recompute measure by measure from left to right and STOPS as soon as a measure without any change is met.
Because then all other measures to the right won't be impacted.
All current simple change will affect the current measure and possibly one or maximum two to the right and the program would respond instantanously.
I know, I know, easier said than done.

Reply

• Mar 13, 2019 - 19:49

Actually, only from the measure just left of the leftmost one currently in view until it doesn't change. But I think the problem comes from how to let the computer figure out if something changed, because currently I think the internal representation considers a measure shifted a millimeter to the right or left as a change, even though nothing else changed.

Reply

• Mar 13, 2019 - 21:26

Precisely. As explained in previous threads on the subject, a change that widens any measure therefore shifts the position of every element in every measure after that. It would indeed be possible in theory to just add an offset to everything not actually recalculate everything from that point on from scratch. I made a quick effort at this and things were crashing like crazy so I gavce up, but no doubt someone sufficiently motivated could figure it out.

Personally, I'm more concerned with figuring out why some people are seeing continuous view in 3.0 be so much slower than 2.3.2 that they can actually notice. When I've done measurements as controlled as possible, I come up with about a 20% slowdown. Unfortunate, sure, but nothing I'd lose sleep over considering how much better everything else is overall and how much else there still is to work on. If I were regularly seeing continuous view so much slower it made it unusable compared to 2.3.2, I might change my mind. But thus far I just haven't seen example of the difference being any more than 20%. So if people do have examples of scores with more significant slowdown, I would be interested to check them out. Could well be something else going on with those specific scores.

Reply

• Mar 13, 2019 - 21:50

Can you try the rectangular selection test I described above? There's definitely much larger difference than 20%. I don't have the tools to really measure it, but I would estimate 3.0.5 is at least 10x slower in that test than 2.3.2. I used this score to test: https://musescore.com/user/496531/scores/4998592
With 2.3.2 selection rectangle updates a few times per seconds, but in 3.0.5 it updates only once every few seconds (On my PC using this score).

I thing there are two separate issues. One is about an editing performance and another is about a general performance in continuous view.

Reply

• Mar 13, 2019 - 22:04

So, you specifically mean Shift+drag to select? I can indeed confirm that particular operation is slow for some reason. I don't recall anyone reporting this before, so thanks for reporting it! For the record, that's not the recommended way of selecting things anyhow, better is normally to use any of the other methods like click / shift+click etc.

Reply

Do you still have an unanswered question? Please log in first to post your question.