http://codereview.appspot.com/5626052/diff/23001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
http://codereview.appspot.com/5626052/diff/23001/lily/axis-group-interface.cc#newcode659
lily/axis-group-interface.cc:659: vector<Grob *> *riders)
On 2012/02/16 10:08:39, MikeSol wrote:
On 2012/02/16 08:09:10, joeneeman wrote:
> I don't understand why riders are necessary. Is it because of this
cyclic
> dependence stuff?
Not cyclical, but imagine that a grob (say tuplet bracket, for
example) has its
outside staff priority set whereas one of its Y_AXIS children (say
tuplet
number, for example), doesn't. If the tuplet number's skyline is
added to the
skyline_pair using add boxes before its parent is shifted, it will be
placed too
low in the skyline. Thus, it must be added to the skyline only after
its
parent's outside-staff-priority has been set to SCM_BOOL_F. This is
why riders
are used.
Could you document this reasoning, please?
http://codereview.appspot.com/5626052/diff/23001/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/5626052/diff/23001/lily/skyline.cc#newcode668
lily/skyline.cc:668: Skyline::left () const
On 2012/02/16 10:08:39, MikeSol wrote:
On 2012/02/16 08:09:10, joeneeman wrote:
> This is linear in the number of buildings, but it should be
constant.
How would one do this?
The buildings are in increasing order, so this should work:
Real last_end = -infinity_f;
for (...)
{
if (i->y_intercept_ > -infinity_f)
return last_end;
last_end = i->end_;
}
return infinity_f;
http://codereview.appspot.com/5626052/diff/23001/lily/skyline.cc#newcode680
lily/skyline.cc:680: Skyline::right () const
On 2012/02/16 10:08:39, MikeSol wrote:
On 2012/02/16 08:09:10, joeneeman wrote:
> Ditto
Ditto
...and here it's a doubly-linked list so you can iterate backwards.
http://codereview.appspot.com/5626052/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
