The algorithm to detect collisions was changed for performance reasons.
The skyline algorithm is very fast compared to the previous approach
especially if the number of elements to compare is big.
To solve the special case you saw i can imagine to look for neighboring
elements in case the skyline routine tries to move an element more than
the element height.
On 11.10.2018 00:49, Tommaso Cucinotta wrote:
Hi,
I'm seeing this new skyline stuff for the auto-placement of elements,
which, from the current master, ends up as in the attachment, when
opening a MIDI file with an excess of tempo change texts to be placed.
There was the same problem a few months ago, but as the code was based
-- AFAICR -- on the shape concept, I could apply a patch I had to fix
the problem, by checking whether the new text to be placed had a rect
intersecting with any of the rects of elements already placed. See the
image comparison between the 2 cases here, for example:
https://musescore.org/en/node/271854
AFAICS, this is not possible anymore, because the skyline abstraction
hides details of what's between the skyline and the score.
What is the rationale for the change ? Is it possible to recover
something back from the previous logic/code here ?
Thanks,
T.
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
