On Feb 16, 2012, at 1:41 PM, Janek Warchoł wrote: > On Wed, Feb 15, 2012 at 3:25 PM, Reinhold Kainhofer > <[email protected]> wrote: >> On 06/02/2012 18:50, [email protected] wrote: >>> In my opinion, these times are too high to justify the gain >>> that one gets from using fine-tuned vertical skylines. >> >> Agreed. > > I strongly disagree. The gain is enormous - how much time would it > take to correct all these issues by hand? (not mentioning that manual > corrections will break every time layout changes!) >
Note that this whole "slow down" thing is much less relevant now that it was before. My current benchmarks show a 0.2-2 second per minute slowdown depending on the file. > I have one thought concerning computation time. > From what i see, currently every stencil's skyline is created from 10 > boxes. That's a good amount for medium-sized slur, but it's not > necessary for a short (~5 ss long) tie, or a clef. And it's > definitely overkill for an accidental; on the other hand, full-line > phrasing slur should have much more boxes. > Maybe it would be feasible to have varying amount of boxes for > different objects? In it's simplest form, the number of boxes could > depend on object's width. This is not impossible, but I'd encourage everyone to do some benchmarking on their favorite scores in order to see the performance hit taken. Janek's right that certain grobs need more boxes than others and that this is a brute force approach, but even with the brute-forcitude of the approach, I still think that the performance hit is minimal. A later patch can suggest gradations in the number of boxes that are user settable (for the moment there are only two, and they're easy to spot in stencil-integral.cc - CURVE_QUANTIZATION and ELLIPSE_QUANTIZATION). This'd take rewriting stencil-integral.cc to look more like beam-quanting.cc (creating a class instead of a series of functions) which, again, is doable, but the change is already so huge that I want to just get it in the code more-or-less bug free before re-tinkering with it. Cheers, MS _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
