fix #276141: no space for lyrics in continuous view #6307
Conversation
Resolves: https://musescore.org/en/node/276141 A common complaint since the release of MuseScore 3 is that we no longer allocate additional space between staves for lyrics and other elements above/below the staff, when in continuous view. That's because these calculations in page view can be optimized so they only need to be done for affected systems on each layout. In continuous view, there is only one system, so it would mean a full layout, which is very slow. But MuseScore 2 did this, and people writing vocal music especially were accustomed to this automatic staff spacing. Since lyrics were about the only thing that did this spacing, it wasn't as expensive as it would be using MuseScore 3 autoplace. And yet, MuseScore 2 was extremely slow with large scores, because it lacked any range optimizations, even in page view. This change finds a compromise that should work well. On the initial layout in continuous view, we do build a full skyline, so it is easy enough to add space for each staff then, and any performance penalty is paid only at that time. Any extra space needed for this is remembered for subsequent layouts. On future layouts, we do use a range, so we only have a partial skyline. The code here calculates the space needed just within the current range, but it also compares this with the remembered value, so uses whichever is larger (and remembers this new value if different). The result is that the spacing is correct when first opening the score, or when first switching to continuous view. After that, any edits that *increase* the required space (such as adding a new verse of lyrics) will do so as expected. If you later make a change that reduces the amount of space requires, we cannot reclaim that space, since a full layout would be required in order to detect that we truly don't need the space anywhere. But you can always reclaim it by switching to page view and back. The code to do the partial skyline comparison is not free, but it happens only once per staff per layout, so in theory it should have a negigible effect on performance. If this assumption turns out to be wrong, we can switch to the code that skips the partial skyline comparison except on the initial layout. This is included but ifdef'ed out.
MarcSabatella
force-pushed
the
276141-continuous-spacing
branch
from
17ba935 to
cd92ec6
Compare
|
This PR replaces #5068. It uses the same basic approach but is optimized to not require a force a full skyline calculation and comparison for each staff on every layout. The performance impact should thus be very small. The tradeoff is, we cannot detect when we can reclaim the space added between staves - not until you do another full layout. Discussions in the issue thread lead to believe this will still be considered a big win, at a small price. |
|
I don't see what went wrong with the Linux build. Seems everything succeeded then just gave an error during the final packaging? |
|
I had the same Linux GitHub artifact build issue with PR #6306. An issue that had been fixed with #6291, but only for master it seems. Cause found, see AppImage/AppImageKit#1060 See #6309 |
fix #276141: no space for lyrics in continuous view
Resolves: https://musescore.org/en/node/276141
A common complaint since the release of MuseScore 3 is
that we no longer allocate additional space between staves
for lyrics and other elements above/below the staff,
when in continuous view.
That's because these calculations in page view can be optimized
so they only need to be done for affected systems on each layout.
In continuous view, there is only one system,
so it would mean a full layout, which is very slow.
But MuseScore 2 did this, and people writing vocal music especially
were accustomed to this automatic staff spacing.
Since lyrics were about the only thing that did this spacing,
it wasn't as expensive as it would be using MuseScore 3 autoplace.
And yet, MuseScore 2 was extremely slow with large scores,
because it lacked any range optimizations, even in page view.
This change finds a compromise that should work well.
On the initial layout in continuous view, we do build a full skyline,
so it is easy enough to add space for each staff then,
and any performance penalty is paid only at that time.
Any extra space needed for this is remembered for subsequent layouts.
On future layouts, we do use a range, so we only have a partial skyline.
The code here calculates the space needed just within the current range,
but it also compares this with the remembered value,
so uses whichever is larger (and remembers this new value if different).
The result is that the spacing is correct when first opening the score,
or when first switching to continuous view.
After that, any edits that increase the required space
(such as adding a new verse of lyrics)
will do so as expected.
If you later make a change that reduces the amount of space requires,
we cannot reclaim that space, since a full layout would be required
in order to detect that we truly don't need the space anywhere.
But you can always reclaim it by switching to page view and back.
The code to do the partial skyline comparison is not free,
but it happens only once per staff per layout,
so in theory it should have a negigible effect on performance.
If this assumption turns out to be wrong,
we can switch to the code that skips the partial skyline comparison
except on the initial layout.
This is included but ifdef'ed out.