Segments and bbox()

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Segments and bbox()

Marc Sabatella
I've been looking at several unrelated bugs that all boil down to one thing: bbox() not being set properly for some elements during layout.  In particular, for Segment elements.

So my first question is this: are segments *supposed* to have a meaningful bbox()?  They sort of do most of the time - it appears to be wide enough to contain all elements in the segment, although the height of the bbox only extends to the first staff.  However, there are cases where the segment bbox is either not set at all (see http://musescore.org/en/node/35176; the segment for beat 3 of the first measure in the posted score has zero height & width) or else it seems to be set incorrectly (see http://musescore.org/en/node/35496; if you check out the sample score, then extend the barlines to span both staves, the bbox for the key signature segment on the second system is only wide enough to contain the key signature for the first staff).

Assuming segment bboxes *are* supposed to be meaningful, the next question is, where in the code are these supposed to be set?  It's a little convoluted (!), but I *think* the place where it is happening is in Measure::layoutX(), here:

https://github.com/musescore/MuseScore/blob/7ab8acd3a5a80a245f3524a5e6d4c7ac662aa6ef/libmscore/measure.cpp#L3322

The comment on that line  ("??", which goes back to the initial commit) doesn't give me confidence :-).  But it looks like we are setting the width of the *previous* segment based on the distance we just determined we need before *this* segment, which I guess makes sense.

I think the zero width segment on beat three is due to the special handling of non-initial clef segments at the top of the loop - the fact that we skip the whole rest of the loop here:

https://github.com/musescore/MuseScore/blob/7ab8acd3a5a80a245f3524a5e6d4c7ac662aa6ef/libmscore/measure.cpp#L3077

But as much as I've fiddled with internal details *within* this loop, I've never really understood the "big picture" of what goes on here, which is to say I really have no idea what the special handling of clefs is about or how to set the previous segment's width here.

The other Segment bbox issues I've seen lately are with Chord elements, very possibly a result of the all the layout work I did not so long ago in which I was entirely focused on setting *positions* of objects correctly but I have no doubt I didn't always get the bbox calculations right.  So here let me just ask a general question: is the expected behavior that a Chord element's bbox encompass all the Note, Dot, Stem, and other objects within it?
Reply | Threaded
Open this post in threaded view
|

Re: Segments and bbox()

lasconic
Administrator
My understanding is that segment width are not supposed to be meaningful.

But I would love to have a definitive answer from Werner :)

lasconic

2014-10-10 4:44 GMT+02:00 Marc Sabatella <[hidden email]>:

> I've been looking at several unrelated bugs that all boil down to one thing:
> bbox() not being set properly for some elements during layout.  In
> particular, for Segment elements.
>
> So my first question is this: are segments *supposed* to have a meaningful
> bbox()?  They sort of do most of the time - it appears to be wide enough to
> contain all elements in the segment, although the height of the bbox only
> extends to the first staff.  However, there are cases where the segment bbox
> is either not set at all (see http://musescore.org/en/node/35176; the
> segment for beat 3 of the first measure in the posted score has zero height
> & width) or else it seems to be set incorrectly (see
> http://musescore.org/en/node/35496; if you check out the sample score, then
> extend the barlines to span both staves, the bbox for the key signature
> segment on the second system is only wide enough to contain the key
> signature for the first staff).
>
> Assuming segment bboxes *are* supposed to be meaningful, the next question
> is, where in the code are these supposed to be set?  It's a little
> convoluted (!), but I *think* the place where it is happening is in
> Measure::layoutX(), here:
>
> https://github.com/musescore/MuseScore/blob/7ab8acd3a5a80a245f3524a5e6d4c7ac662aa6ef/libmscore/measure.cpp#L3322
>
> The comment on that line  ("??", which goes back to the initial commit)
> doesn't give me confidence :-).  But it looks like we are setting the width
> of the *previous* segment based on the distance we just determined we need
> before *this* segment, which I guess makes sense.
>
> I think the zero width segment on beat three is due to the special handling
> of non-initial clef segments at the top of the loop - the fact that we skip
> the whole rest of the loop here:
>
> https://github.com/musescore/MuseScore/blob/7ab8acd3a5a80a245f3524a5e6d4c7ac662aa6ef/libmscore/measure.cpp#L3077
>
> But as much as I've fiddled with internal details *within* this loop, I've
> never really understood the "big picture" of what goes on here, which is to
> say I really have no idea what the special handling of clefs is about or how
> to set the previous segment's width here.
>
> The other Segment bbox issues I've seen lately are with Chord elements, very
> possibly a result of the all the layout work I did not so long ago in which
> I was entirely focused on setting *positions* of objects correctly but I
> have no doubt I didn't always get the bbox calculations right.  So here let
> me just ask a general question: is the expected behavior that a Chord
> element's bbox encompass all the Note, Dot, Stem, and other objects within
> it?
>
>
>
> --
> View this message in context: http://dev-list.musescore.org/Segments-and-bbox-tp7579004.html
> Sent from the MuseScore Developer mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Mscore-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Segments and bbox()

wschweer9
Only elements which are visible are supposed to have a meaningful
bounding box.
Bbox is mainly used to calculate which elemens we need to redraw on an
exposure
event.
Segment has a maintained x-position but no width if i remember right.
Chord bbox is set and is the outline of all siblings. I am not sure its
still used anywhere.

If the segment bbox is of interest it would be better to recalculate the
values from
context (next segment, staff position etc.).
The calculation of bounding boxes is a bit tricky as width and height of
some elements
are calculated at different stages of layout.

Am 11.10.2014 um 13:27 schrieb Lasconic:

> My understanding is that segment width are not supposed to be meaningful.
>
> But I would love to have a definitive answer from Werner :)
>
> lasconic
>
> 2014-10-10 4:44 GMT+02:00 Marc Sabatella <[hidden email]>:
>> I've been looking at several unrelated bugs that all boil down to one thing:
>> bbox() not being set properly for some elements during layout.  In
>> particular, for Segment elements.
>>
>> So my first question is this: are segments *supposed* to have a meaningful
>> bbox()?  They sort of do most of the time - it appears to be wide enough to
>> contain all elements in the segment, although the height of the bbox only
>> extends to the first staff.  However, there are cases where the segment bbox
>> is either not set at all (see http://musescore.org/en/node/35176; the
>> segment for beat 3 of the first measure in the posted score has zero height
>> & width) or else it seems to be set incorrectly (see
>> http://musescore.org/en/node/35496; if you check out the sample score, then
>> extend the barlines to span both staves, the bbox for the key signature
>> segment on the second system is only wide enough to contain the key
>> signature for the first staff).
>>
>> Assuming segment bboxes *are* supposed to be meaningful, the next question
>> is, where in the code are these supposed to be set?  It's a little
>> convoluted (!), but I *think* the place where it is happening is in
>> Measure::layoutX(), here:
>>
>> https://github.com/musescore/MuseScore/blob/7ab8acd3a5a80a245f3524a5e6d4c7ac662aa6ef/libmscore/measure.cpp#L3322
>>
>> The comment on that line  ("??", which goes back to the initial commit)
>> doesn't give me confidence :-).  But it looks like we are setting the width
>> of the *previous* segment based on the distance we just determined we need
>> before *this* segment, which I guess makes sense.
>>
>> I think the zero width segment on beat three is due to the special handling
>> of non-initial clef segments at the top of the loop - the fact that we skip
>> the whole rest of the loop here:
>>
>> https://github.com/musescore/MuseScore/blob/7ab8acd3a5a80a245f3524a5e6d4c7ac662aa6ef/libmscore/measure.cpp#L3077
>>
>> But as much as I've fiddled with internal details *within* this loop, I've
>> never really understood the "big picture" of what goes on here, which is to
>> say I really have no idea what the special handling of clefs is about or how
>> to set the previous segment's width here.
>>
>> The other Segment bbox issues I've seen lately are with Chord elements, very
>> possibly a result of the all the layout work I did not so long ago in which
>> I was entirely focused on setting *positions* of objects correctly but I
>> have no doubt I didn't always get the bbox calculations right.  So here let
>> me just ask a general question: is the expected behavior that a Chord
>> element's bbox encompass all the Note, Dot, Stem, and other objects within
>> it?
>>
>>
>>
>> --
>> View this message in context: http://dev-list.musescore.org/Segments-and-bbox-tp7579004.html
>> Sent from the MuseScore Developer mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Mscore-developer mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/mscore-developer
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Mscore-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>
>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Segments and bbox()

Marc Sabatella
On 10/13/2014 07:53 AM, Werner Schweer wrote:
> Only elements which are visible are supposed to have a meaningful
> bounding box.
> Bbox is mainly used to calculate which elemens we need to redraw on an
> exposure
> event.

OK, thanks, that makes sense.  I guess it's also used to figure out
which element we are clicking, but again, there is no need for this to
make sense on elements that are not meant to be visible.

> Segment has a maintained x-position but no width if i remember right.
> Chord bbox is set and is the outline of all siblings. I am not sure its
> still used anywhere.

I'm not sure either.  But it's not always correct currently.  At least,
I have found a few cases where it is wrong.  So far, though, I haven't
seen any bad effects, which makes me suspect we don't really use it.  
I'm not sure I want to try to "fix" these cases if there are no actual
problems currently - I'd be afraid of breaking something that used to work.

> If the segment bbox is of interest it would be better to recalculate the
> values from
> context (next segment, staff position etc.).

I had been trying to use it position the end of an ottava, and it worked
well except in the cases where the segment bbox was not set well.  But I
now think using the segment bbox is the the wrong approach anyhow.  It
causes the length of an ottava line to be possibly affected by elements
on other staves, which is not really appropriate.  So I am now instead
looping through the voices on the current staff and taking the rightmost
edge of any chord I find, which is more directly what I want to achieve
anyhow.  Segment bbox width just happened to produce a similar result
"most" of the time. Calculating width by looking at the position of the
next segment is too big - it would include the space up to the next
chord, which is specifically what we are trying to avoid for ottavas.

Marc


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer