On Thu, Aug 02, 2012 at 06:22:49PM +0200, m...@apollinemike.com wrote: > On 2 août 2012, at 18:18, Lucas Gonze wrote: > > > Is it architecturally possible to make a significant amount of > > overhead go away? Are incremental compiles plausible? > > It is very difficult. It's better to use a front-end editor > that shows some sorta mock-up of the score and that only > compiles the nice LilyPond version from time to time (if this > exists). Getting an actual LilyPond score requires calculating > line breaks and there's no way to get rid of the overhead.
Sure there is. Compile each bar individually with the default spacing (i.e. whatever you get if your entire score is one bar and you use ragged-right=##t). The concatenate bars until the sum is larger than the allowable line-width, at which point you put the bar on the next line. It'll be completely ugly (ragged score lines? even finale doesn't do that!), but it eliminates the overhead of line breaks. Then the question is what trade-offs of speed for beauty you want to make. I mean, a slightly less invasive/drastic speed-up would be to have the user hard-code 4 bars per line. That's also ugly, but not as bad as the previous option. In short: if there is a concerted effort to create a "quick render" output, I would be absolutely shocked if it wasn't at least 10 times faster than the current output. Kill line breaks, draw slurs as rectangles, place noteheads on a strict timing grid instead of optical spacing... there's a lot of beautiful things that lilypond does which uses CPU resources. > As for the svg, significant improvement can be made in the speed > of LilyPond's svg export - contributions are certainly welcome > in this area. The backend is very well written but it is all in > Scheme The "compiled scheme" in guile 2.0 could help here. So if anybody feels like picking up the porting-to-guile2.0 work... - Graham _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
