On Fri, Feb 4, 2011 at 1:30 PM, Mike Solomon <[email protected]> wrote: > On Feb 4, 2011, at 10:19 AM, Han-Wen Nienhuys wrote: > >> On Fri, Feb 4, 2011 at 10:08 AM, <[email protected]> wrote: >>> LGTM, but I can't do a regtest today :( >>> >>> >>> http://codereview.appspot.com/4129050/diff/1/lily/beam-quanting.cc >>> File lily/beam-quanting.cc (right): >>> >>> http://codereview.appspot.com/4129050/diff/1/lily/beam-quanting.cc#newcode215 >>> lily/beam-quanting.cc:215: } >>> Very cool stuff! >>> I won't have time to do a regtest today, but I see what you're doing and >>> it makes a lot of sense. >>> One suggestion: perhaps we should create an enum: >>> enum Stem_dir_scenarios { ALL_UP, ALL_DOWN, DOWN_TO_UP, UP_TO_DOWN, >>> WACKY } that provides a tag for the beam which is then used in this >>> function. My rationale is as follows: >> >> It's for dealing with UP/UP and DOWN/DOWN configs for the outer stems. >> Collisions that fall below (for UP/UP) the edges of quant_range will >> never really collide. UP/UP and DOWN/DOWN are the normal >> configurations, so they would account for 99% of the beam cases. >> > True, although I think it's important to account for all beaming cases if > possible.
This is a performance optimization, ie. a way to run collision detection without performance impact if the object does not really collide, so it does not need to deal with all cases. -- Han-Wen Nienhuys - [email protected] - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
