lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: address@hidden
Subject: Re: Gets vertical skylines from grob stencils (issue 5626052)
Date: Wed, 22 Feb 2012 09:57:13 +0100

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.

> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]