On Fri, 17 Aug 2012 10:16:25 -0700, <mts...@gmail.com> wrote:
http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode780
lily/axis-group-interface.cc:780: while (dirty);
On 2012/08/17 08:12:56, Keith wrote:
I am beginning to understand the new code. Would you consider again using
distance() instead of the repeated calls to intersects() in the while(dirty)
loop ? It might look simpler now that you've been away from the code
for awhile.
floors[j] = padding - forest[j][UP]~distance~pair[DOWN]
ceilings[j] = forest[j][DOWN]~distance~pair[UP]
You know the solution will be to move an amount equal to one of the floors[j],
and you want to find the smallest that fits, so make
trials = sort (floors)
and find the smallest among trials that satisfies
trials[n] > 0
&& for all j (trials[n] > floors[j]
|| trials[n] < ceilings[j] )
I am not adverse to using distance if possible - my trouble case is the
following.
AAAAAAAAA
BBBBBBBBBBBBB
Image that object A above is placed first and LilyPond is now
considering whether it should leave B where it is or place it above A.
The distance function would dictate that it needs to be shifted above A
because its DOWN skyline is below A's UP.
We need not let the distance function between A[UP] and B[DOWN] dictate,
because having positive distance between A[DOWN] and B[UP] is another solution.
Object AA, a member of the forest, sets two constraints
floor = padding - AA[UP] ~distance~ BB[DOWN]
ceiling = AA[DOWN] ~distance~ BB[UP] - padding
and we are checking that a trial location satisfies
(trial >= floor) OR (trial <= ceiling)
I suppose you show BB having been placed just above the staff, and that it
still lies below the ceiling set by AA, so this trial position satisfies the
first test in the OR above, so we win.
All these distances can be computed once, before raising the skylines at all,
because they tell you right away what trial values of raising BB will clear AA.
That would be much simpler for people like me to understand than computing the
four intersects() conditions, after having moved the skylines by zero or more
bump(s).
On the question of where to store padding, simple padding was previously added
by the code using distance(). That seems best because it is a simple addition
and different applications might have different padding to the same objects.
Then you don't have to worry about adding padding multiple times to a skyline,
deciding which of two skylines to pad, etc.
The other thing is 'horizon-padding' which fattens the buildings in the skyline
themselves, and has in the past been implemented by reshaping the Skyline
object. The user-variables skyline-(vertical|horizontal)-padding apply so far
to symmetric situations, and the code simply horizon-pads both skylines so you
get the effect of twice the number you enter.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
