[gsharp-devel] Re: [gsharp-cvs] CVS update: gsharp/drawing.lisp gsharp/measure.lisp gsharp/packages.lisp

[Christophe Rhodes]

Robert Strandh <strandh at labri.fr> writes:

> Christophe Rhodes writes:
>  > This change causes a problem: compute-staff-group-parameters is only
>  > called if the element containing the staff group is modified; however,
>  > the final accidentals need to be recomputed if the staff's key
>  > signature changes (and also, in my working copy, if a key signature
>  > has been inserted earlier on the staff...)
>
> I fixed this problem by invalidating layers using the staff that has
> it key signature changed.  

Thanks.  (As you'll see in my previous message, I've updated my key
signature work-in-progress patch)

> However, I am no longer sure that my moving the computation cited
> above was a good idea.  Here is the dilemma:
>
>   * in order to produce a good line-breaking result, we need to know
>     the physical width of elements as accurately as possible.  This is
>     an argument in favor of computing accidentals early. 
>
>   * however, accidentals depend on key the signature of the staff.  So
>     when the key signature changes, we must invalidate large numbers
>     of elements, with increased computations as a result. 

Right.  One could save a fair amount of this by only invalidating
those elements with a note matching the change in the key signature,
but this could be either too messy or an abstraction violation.

> The question, then, is whether we need the extra accuracy for
> line-breaking, or whether we can do an approximate job computing the
> widths of some elements and then try to do a better job when rendering
> the final page.  
>
> I am now leaning towards NOT computing accidentals before estimating
> physical dimensions, but I am not going to change the code again at
> this point.  We'll see when we start having large scores whether this
> is a problem.  For all I know, recomputing the entire score is a
> matter of a few seconds, in which case invalidating lots of elements
> is not a problem.   

I don't know what the right answer is either; the current code seems
at least workable.

Cheers,

Christophe