[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Gets vertical skylines from grob stencils (issue 5626052) Joe Neeman Wed Feb 22 02:00:21 2012

On Wed, Feb 22, 2012 at 12:57 AM, [EMAIL PROTECTED] <

> On Feb 22, 2012, at 9:48 AM, David Kastrup wrote:
> >
> >> 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.

Bear in mind that the reason we currently handle padding the way we do is
so that it affects the distance between staves but it doesn't force
outside-staff-grobs too far away. Really, though, you should just pick
something that's easy to implement and offers the user some flexibility.
Padding is currently done the way it is because that's what came to my mind
at the time; no need to keep it that way.

lilypond-devel mailing list