Bad layout of pages >1 after edit
I saw this for a moment with one of my scores but couldn't reproduce. Now I have a score where it reproduces every time on initial load. Goes away on relayout of the page and doesn't come back during that session.
1) load attached score, take the reset
2) view page three
Result: huge empty space at top of page, everything else compressed to the point of overlap at the bottom of the page.
If you don't take the reset, it's fine, but then if you reset or delete the "Major pentatonic" text that is forcing too much space between the first two systems, then it happens.
I figured at first that this had to be related to my system spacing changes, but it might not be, as I can reproduce in a nightly build I have from back in March as well, long before my changes were made.
A little poking around shows some very strange things, going on, most notatbly, that measures 22 & 23 seem to exist in systems on both page 2 and page 3! This led me to suspect the rangeDone rollback from #4373 could be involved, but that seems not to be the case either, as I can reproduce with that change reverted. But somehow, I think the same system (literally the same pointer, as the object debugger keeps flipping me to one of them when clicking the other) has been added to both pages.
| Attachment | Size |
|---|---|
| Scale Method Demo.mscz | 47.78 KB |
Comments
I can reproduce similar behavior from scratch as well:
1) new score, treble clef template, 400 measures (really, any score that extends to two full pages)
2) add spacer down to first measure
3) extend far enough to push two systems to next page
4) delete the spacer
Result: too much space at top of the second page, and object debugger similarly shows systems belonging to multiple pages
I now think it has to do with how we initialize the system list when starting to layout a page, we're still thinking the previous system is there when it shouldn't be.
I can reproduce these effects going back to the alpha, which is the earliest build I have. The only somewhat relevant change to the code I see within the past year was https://github.com/musescore/MuseScore/commit/d8fa8f8c6237f989e345e1379…, but I don;t see anything in the way the code was structured before that to lead me believe this ever worked. What I think we need is the equivalent of "systemOldMeasure" to track when we've reached a page that hasn't changed - "pageOldSystem" or some such. Or just keep collecting pages for the sake of recomputing system positions, not actually laying out the systems. But that means doing a bunch fo skyline calculations we don't need to be doing, so better to figure out when to stop.
The msot relevant place to do it is the line Dmitrio flagged as FIXME in the referenced commit, but that does appear to be what the previous was doing as well. There just doesn't seem to be a place where we realize we need to continue updating systems until we reach a page that hasn't changed. So I will look at adding code for this.
I have it working, pretty simple fix, but want to continue testing in the morning.
https://github.com/musescore/MuseScore/pull/5081
I have updated the title to reflect the true nature of the problem. In short: if edit affects the height of a system enough to change the number of systems that fit on that page, we don't bother re-laying out the next page. So if a system should move to the next system, it just disappears:
Conversely, if a system should move from the next page onto this page, a hole is left at the top of the next page where the system was, and the remaining systems end up being stacked directly on top of each other:
All that is needed to fix this mess is a change to end condition for the page collecting loop, to check that we really are done with the range and that the page ends with the same measure it did on the previous layout, so that is what my PR here does.
Fixed in branch master, commit f1395cdd62
fix #290210: bad layout of subsequent pages after edit
Automatically closed -- issue fixed for 2 weeks with no activity.