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

[Robert Strandh]

Christophe Rhodes writes:
 > Robert Strandh <strandh at labri.fr> writes:
 > > 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.

Neither, I think.  Again, if we could rely on the segment to delimit
the effect of a change in key signature, then the number of measures
to be recomputed would be limited.  But if it can effect a very large
score, it might just be too expensive. 

 > > 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.

Yes, although invalidating the measure computation should probably be
done in an :after method on (setf key-signature) on a staff, and not
in the GUI. 

I suggest keeping the code as it is for now.  
-- 
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.
---------------------------------------------------------------------