Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skylines construction optimization #4768

Merged
merged 2 commits into from
Mar 6, 2019

Conversation

dmitrio95
Copy link
Contributor

This pull request is intended to optimize skylines construction process in two ways:

  1. Staff lines are added to the constructed skyline before other elements. As a large part of other shapes usually lay below the skylines such shapes do not get added to skylines separately which reduces a number of the constructed skyline segments. This can speed up both skyline construction and its later usage.
  2. Use a binary search for finding a position to insert new skyline segments. This requires tracking x coordinates of the skyline segments but this makes it possible to get rid of the linear search of the segment insert position which makes the process of skylines construction faster.

As this optimization concerns only score layout it presents very little (≈3%) difference while testing on score conversion to various fileformats (like it was performed here). However more specific benchmark (mtest benchmark) shows a difference on layout operations. Here are the results of running that test on the OpenScore edition of the Mozart's Symphony No.41 ("Jupiter") that was converted to MuseScore 3 fileformat, the benchmark was run for 5 times, and average results are presented here. All results are presented in milliseconds (except the percentage difference). Errors are calculated as standard deviations for the benchmark results set.

benchmark master (March 4, 21e5a7c) Optimized skylines Difference, %
Score reading 558.6 ± 6.7 563.2 ± 20.0 -0.8
Full layout (benchmark1) 949.8 ± 8.3 883.8 ± 21.5 6.9
Full layout (benchmark2) 968.6 ± 18.3 880.0 ± 5.9 9.1
Partial layout 69.6 ± 0.9 63.2 ± 1.1 9.2

The results show that this optimization indeed does not influence score reading (without performing a layout) while making a performance gain of about 7—9% for layout operations.

@@ -3508,6 +3508,9 @@ void Score::layoutSystemElements(System* system, LayoutContext& lc)
if (!mb->isMeasure())
continue;
Measure* m = toMeasure(mb);
if (MeasureNumber* mno = m->noText(staffIdx))
ss->skyline().add(mno->bbox().translated(m->pos() + mno->pos()));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, could be worth also adding a check for mno->autoplace() before adding to the skyline. It's one of the few such things I didn't do in my PR #4730. I figure I'll need to update that anyhow if this gets merged first, though.

@@ -3535,7 +3538,6 @@ void Score::layoutSystemElements(System* system, LayoutContext& lc)
}
for (auto n : c->notes())
notes.push_back(n);
std::list<Fingering*> fingerings;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, thanks!

@anatoly-os anatoly-os merged commit fc515c4 into musescore:master Mar 6, 2019
@dmitrio95 dmitrio95 deleted the skyline_opt2 branch June 3, 2020 09:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants