Layout shift on first layout after load
Windows 7, GIT commit: c20b96e
1) open attached score
2) position view to be able to see third system - I see four measures (9-12)
3) Ctrl+A or any other operation that forces a relayout
Result: a fifth measure (13) appears on the third system
I see things like this from time to time and they always bother me a little but tend to be hard to pin down. This one is completely reproducible for me, and even reducing the measure spacing from 1.300 to 1.295 and resaving does not change anything - the initial layout is still more conservative than the subsequent one. So it's not just round-off error as I once might have assumed. Knowing what I do about layout, I might instead guess that Score::computeMinWidth and Measure::layoutX are disagreeing about the amount of space needed for some measure, but I have only a very narrow view of layout, and I actually suspect this might be something broader. There is too much going on for me to see what the problem might be, but I fear a big can of worms.
I might also guess that a cheap fix would be to force an extra layout after load.
| Attachment | Size |
|---|---|
| Reunion-20-140506.mscz | 7.48 KB |
Comments
On further investigation, I do still see problems, but it's back to being hard to pin down exactly how to reproduce, unfortunately.
If someone wants to try to reproduce, the original file might not do it. Try opening the original 1.3 version of Reunion, changing Style / General / Measure / Spacing to 1.3, and saving that. No guarantees, though.
A possible relevant clue: when I see these problems in this score, the pedal lines also become "off". Since the score was created in 1.3, there was no automatic positioning of pedal lines, so they have explicit positioning in the MSCZ file. Normally, these seem to get converted well to user offsets, but in this score, when this bug gets triggered, the layout shifts but the pedals stay in their old locations, or move in apparently random ways.
One other thing I should mention - in (version) 1.3, the score had (value of) 1.3 as the measure spacing, but we are automatically reducing that by 5% for old scores to try to match layout better. So it will show up as 1.235. That's why you might need to change this back to (value of) 1.3 to reproduce any of this.
It is *possible* that this is fixed by https://github.com/musescore/MuseScore/commit/d90b918dca68a0cd69ec56222…. At least, I cannot reproduce using any of the permutations I used before. One might think that fix wouldn't likely relate to layout, but given there *is* a time signature with a courtesy signature at the start of the problem system, and given the apparent connection between this bug and #25675: Beaming changes after two layout operations, I am "somewhat" hopeful.
I'm leaving this open for now and will re-test from time to time (it's still on my "Hit List").
Still cannot reproduce. I'm closing.