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 <[email protected]>: >> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
