On Feb 22, 2012, at 9:48 AM, David Kastrup wrote: > "m...@apollinemike.com" <m...@apollinemike.com> writes: > >> Hey all, >> >> I've uploaded a first-pass attempt at implementing the suggestion that >> Joe talked about (using buildings directly in the skylines). >> This saves a lot of time in the calculation of skyline distance (time >> spent in Axis_group_interface::skyline_spacing can go from 2 to 0.2 >> seconds for scores with lots of beams and hairpins). >> >> However, the global time takes a huge hike with this patchset because >> skylines are constantly being rebuilt with padding added on. > > It would appear to me that one would want to implement padding > operations working on whole readily-built skylines. That should be more > efficient than padding the individual elements. >
The question boils down to this: Grob X (say a NoteColumn) has skyline A. Grob X's skyline is subsumed in grob B's (say a PaperColumn) skyline Y. Grob X has skyline-horizontal padding of 0.15 and Grob Y has skyline-horizontal-padding of 0.1. Does this mean that grob X, when subsumed into grob Y's skyline, has a resultant skyline-horizontal-padding of 0.25? My inclination used to be "no", but over the past 24 hours my brain has come around to "yes" as I see the assumptions that the code is written on. I think that padding needs to be built into skylines at creation time, always. > I would consider it perfectly tenable if we needed to rethink our > padding specifications to better work in the context of full skyline > interaction. So if a particular kind of padding hack we implemented in > the context of rectangular skylines does not map well to more accurate > skylines, it is perfectly valid to replace it by different padding kinds > that are a better match to what we actually do. For example, some > horizontal skyline padding was designed to prevent excessive > interlocking. If the skylines are no longer rectilinear, strictly > horizontal padding makes only very limited sense. > I agree that things need rethinking. I'll hopefully have a clean patch set up soon w/ a better use of padding that doesn't mess any old stuff up while allowing the new changes to take effect in reasonable compile time. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
