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

[Robert Strandh]

Christophe Rhodes writes:
 > rstrandh at common-lisp.net (Robert Strandh) writes:
 > 
 > > moved the computation of the final accidental (determine whether
 > > one should be displayed or not according to the key signature) from
 > > drawing.lisp to measure.lisp.
 > 
 > 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.  

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. 

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.   

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------