When navigator is on the graphic update is very slow
Reported version
3.0
Type
Performance
Frequency
Few
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
Using Windows 7 on an i7 laptop, with version 3.0.5
1) Open or create a relatively long score (several pages)
2) Select Continuous view (in page view the problem is less severe)
2) Open navigator
3) Any attempt to drag the score lags or is sluggish
Comments
Confirmed, navigator really seems to make a large difference in Continuous view.
"Frequency" refers mostly to a number of independent reports or mentions so I change that field to "once" for now.
This happend to me in 3.5 with Linuxmint mate 19.3 Tricia
30gb RAM
I have also experienced this in 3.6. I would argue for higher Severity because the speed of Navigator updates affects any editing operation of the whole program. It can be pretty frustrating to edit notes when the score grows to a few hundred bars, unless the navigator window is closed.
Can navigator updates happen in a different thread? It won't matter if the view is a second or two behind, but interactive editing operations need to remain responsive.
Can layout recalculations be terminated early if the edit does not cause changes later in the document? i.e. if editing a note changes the length of a bar, this often won't affect the display any further ahead than the current stanza. Especially if there are explicit line breaks and page breaks later in the score.
First reported with 3.0.5
We already have the code to do the partial layout, that's why editing can be fast when not using the navigator. So the question is, why doesn't the navigator do the same? Probably it should, but I'm not familiar with the navigator code.
Still, compared to other issues we identify as "major", this one is nowhere near as serious. The navigator isn't needed and probably used by only a small percentage of users (mostly ones who became accustomed to it many years ago when it was enabled by default), and remains unnecessary given all the other ways of navigating. And one can simply close it when not actively using it. So the workarounds are trivial.
I recently made my first MuseScore score that went over a few dozen bars, and found performance noticeably dipped around 75 bars and has become painfully slow (like 1 FPS) at 158 bars. There are 10 staves. I have been using the navigator panel to jump around to different sections of the score, and recently found from reading here that the problem only occurs when the navigator is open when in Continuous View. As we eagerly await a fix, could you elaborate on the trivial workarounds that you mentioned? (Without the navigator, the only way I'm aware of to change which part of the score I'm looking at is to scroll or click-and-drag with the mouse wheel, which are useful features in their own right, but obviously poor substitutes for the navigator.)
Instead of the navigator try the timeline. Also see https://musescore.org/en/handbook/3/keyboard-shortcuts#score-navigation
The navigator is never needed just to move around, nor is dragging the score. The standard / simple way is the same as pretty much any other program - use the mouse wheel to scroll vertically, add Shift to scroll horizontally. You can also the usual Lage Up/Down keys, or use the standard shortcut for Ctrl+F to open a "find" dialog that lets you jump by measure number or rehearsal mark.
In reply to The navigator is never… by Marc Sabatella
The problem is not when going a few bars far or when navigating vertically, but when one needs to go dozens of pages forward or backward. The use of the mouse wheel is painfully slow. An as there isn't either a scroll bar, this simple task is difficult and time-consumning .
The timeline mentioned by Jojo-Schmitz I recall (I'm not with the program open right now) it has too much stuff to be useful just for scrolling forward or backward.
A problem with the navigator is that it is meant to contain a full version of the score, when that is cleraly unnecessary. When there are several pages it is almost impossible to really differentiate pages by their visual content. The page number is most times enough.
Two possible solutions (which might coexist and be selected or enabled by the user) are a simple horizontal scroll bar at the bottom of the score area and a new kind of navigator where only the page numbers are shown. With an intelligent scroll bar that shows also the number of page when scrolling, as in most word processors and document viewers, the page-number navigator would be unnecessary.
In reply to The problem is not when… by fmiyara
Having (as an option for users who would not like them) scroll bars is indeed a very desirable feature... Several discussions already take place here with supporters and opponents...
I believe scroll bars may be coming in MuseScore 4.
But meanwhile, I suspect you probably aren't giving the timeline a fair chance. The extra information it provides is actually extremely useful - far more useful than page numbers. I almost never know I want to jump to "page 27" (and if I did, I'd simply use the find command to jump there directly). Nor do I ever know I want to be "dozens of pages" forward and know exactly what that spot is. Much more often, I want to go to "the place where the brass comes in", or "the key change to Ab", or the "Andante" section. That's exactly the info the timeline provides so much better than the navigator.
So if you have a real world score and use case where you are having trouble conceptualizing how to use the timeline, feel free to start a forum thread for further discussion, and maybe we can find ways of helping you see how to use it more efficiently while awaiting the eventual introduction of scroll bars.
Meanwhile, the person to whom I was responding was not talking about scrolling through dozens of pages - it was a relatively short score of only 75 bars. And he specifically indicated he didn't know of any alternatives other than dragging, thus suggesting he simply was not aware of the scroll wheel or page up/down or timeline or find. Hence, my reply offering useful information to that person. And when you post your score and specific question to the forum, we can try to offer useful information to you as well.
Scroll bars will be a very welcome addition to MuseScore 4!
I didn't dismiss the timeline, I just meant it is too much a tool to just going ahead a lot of pages (75 or 158 bars is, at any rate, too much to use the scroll wheel of the mouse, especially in the case of a large orchestral score).
Even if I never have needed it, I acknowledge that the timeline may be very useful for many people, but not for this since it takes too much room from the screen, and when your sistem is a laptop with a small screen, screen area is at a premium.
You mention your experience and how you would proceed, and it is OK, but please consider that other people may have a different style of interaction with the computer. I know you are very fond of key shortcuts. I'm not because I have a difficult time trying to remember all I would need, so I use them sparingly, but at the same time I have no difficulty remembering that the target page is No 27, or by the same token, that it is close to such and such approximate percentage of the full score.
That's why a great program is even better if it provides several ways to do the same things so that the user can choose according to their preferences.
My point isn't to debate the merits of possible feature requests. This isn't the place for that. I'm merely trying to help the user who expressed difficulty. If you have advice to offer meanwhile that is relevant to the topic at hand, I'm sure it would be welcome.