Re: Gets vertical skylines from grob stencils (issue 5626052)

[Joe Neeman]

On Wed, Feb 22, 2012 at 12:57 AM, address@hidden <address@hidden> wrote:

On Feb 22, 2012, at 9:48 AM, David Kastrup wrote:

> "address@hidden" <address@hidden> 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.

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.

Cheers,

Joe