Layout jump due to bad cautionaryWidth() calculation

• Mar 12, 2017 - 19:06
Reported version
2.1
Type
Functional
Severity
S3 - Major
Status
closed
Project
MuseScore

Windows 10, GIT commit: c90a7e0

This is a followup to #109021: Hairpin and other symbols are shifting when relayout occurs. As I imagined, there *are* other cases where you can get the same sort of layout shift on first relayout after load, with presumably the same "wandering hairpin" type of side effects. The problem with the score in that issue was with widths of repeat barlines. But there is also a problem with double bars generated as part of a courtesy key signature. You can see it with the attached score:

1) Load, verify measure 3 is at end of first system
2) press Ctrl+A

Result: measure 3 jumps to the next system

This happens because our estimate of the width of the courtesy key signature that would be needed in order to fit measure 3 at the end of the first system does not account for the double bar that also gets added. It shouldn't be too hard to add this to cautionaryWidth(). We just need to do a similar thing as we do for the key signature itself - check across all staves to make sure there isn't one already, then keep a running "max" value to figure out the widest the generated barline would end up being.

Attachment Size
cautionaryWidth.mscx 15.01 KB

Comments

• Mar 12, 2017 - 20:10

With the following file, the layout jumps back and forth on each Ctrl+A, due to the same cause. Actually, it does on the other too, but I'm attaching this to remind us to consider multiple staves and the possibility of different barlines on each, which is trickier than it seems at first. But I do have a tentative fix.

Attachment Size
cautionaryWidth - flip.mscz 7.65 KB

Reply

• Mar 13, 2017 - 03:34

Been playing around with this more, it definitely improves things at lot. Probably not 100% perfect, and every once in a while I still see a slight discrepancy in calculated widths after layout with some combinations of barline types and staff scaling - not by enough to cause a jump, though. And then when I try again, I can't reproduce the discrepancy at all.

In any case, the more common case where all staves are the same size and have the same barline type definitely seems to work well.

I actually added the commit about to the same branch as my previous PR and thought that would show up in the PR, but it didn't. Do I need to submit a new one? Or does someone else want to take this code and play with it a bit more and submit one themselves?

Reply