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: Fri, 17 Feb 2012 08:47:19 +0100

On Feb 16, 2012, at 1:41 PM, Janek Warchoł wrote:

> On Wed, Feb 15, 2012 at 3:25 PM, Reinhold Kainhofer
> <address@hidden> wrote:
>> On 06/02/2012 18:50, address@hidden 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


reply via email to

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