Opensheetmusicdisplay: Performance: optimize SkyBottomLineCalculator

Created on 14 Jan 2021  路  3Comments  路  Source: opensheetmusicdisplay/opensheetmusicdisplay

For very large scores, OSMD can take a lot of time to render (e.g. Actor Prelude, our largest sample in the demo).

It looks like SkyBottomLineCalculator.calculateLines() takes the bulk of the time (~96.1% of render()), and ctx.getImageData() (Vexflow) a large part of that (~57%).

image

Maybe we can optimize something here - either getImageData() in Vexflow or the rest of the calculateLines() function in SkyBottomLineCalculator.

@bneumann maybe you could help out here a bit as well, since you know the SkyBottomLineCalculator pretty well.

(of course, the goal is not to make the Actor Prelude sample render extremely fast, it's an extremely large sample that's unrealistic for most uses.
also note that the 17 seconds are on a pretty old dual core cpu from 2012, 2.9Ghz )

enhancement performance

Most helpful comment

Yes that part's always been a problem. What we do here is, that we prerender all measures off-canvas and check for the boundaries. @matt-uib and I were discussing that methodology a lot. The alternative would be to properly implement all bounding boxes (which were not done at all at the time of the implementation of the skybottomcalculator) and only do some math over those boxes.
This would have 2 benefits and 1 drawback:
Pro:

  • Faster
  • Can be done in a backround job where you don't have a canvas
    Con:
  • Precision loss because we for instance beams might get a rectangular box while they are actually more triangular shaped.

Anyways, I will look into it if I find some time. Been quite blocked due to Corona :(

All 3 comments

Yes that part's always been a problem. What we do here is, that we prerender all measures off-canvas and check for the boundaries. @matt-uib and I were discussing that methodology a lot. The alternative would be to properly implement all bounding boxes (which were not done at all at the time of the implementation of the skybottomcalculator) and only do some math over those boxes.
This would have 2 benefits and 1 drawback:
Pro:

  • Faster
  • Can be done in a backround job where you don't have a canvas
    Con:
  • Precision loss because we for instance beams might get a rectangular box while they are actually more triangular shaped.

Anyways, I will look into it if I find some time. Been quite blocked due to Corona :(

I wonder if using an existing collision library that's used in game engines would help here. They're typically optimized and well-tested. Here's an example of real-time collision detection with lots of non-rectangular objects.

I think the problem is getting the bounding boxes in the first place, because vexflow doesn't always give them, so we have to check where it draws things, basically pixel by pixel for now. Checking for collisions is the lesser problem.

Was this page helpful?
0 / 5 - 0 ratings