George_ wrote: > WRT (1): Someone in this thread suggested using individual threads to render > a bar at a time. The end result would be messy, but what if one or two > threads were dedicated to running 'behind' the main threads to clean up and > knit together output?
Multithreading works well when there are "natural" subdivisions of the work. It's really hard to come up with a "natural" subdivision for Lilypond. Bars are not particularly fundamental to Lilypond music. Bar lines are just another thing that get engraved. Plus, Lilypond does not require that all staves in a system have the same bar structure. Dividing into systems would be convenient, but you don't really know where the next system starts until you're done with the current one. Having done quite a lot of threaded programming, when I think of the job Lilypond is doing, I don't see any natural breakdown. It's a very sequential process. Now, it might be possible to have one thread producing an internal representation of the score -- kind of an intermediate language -- and have another thread sucking on that representation and blowing PDF or EPS or MIDI or whatever. Even that would only be possible if the internal representation did not change fundamentally after it was created. When I see status messages that say, for example "fitting music onto 4 or 5 pages", that leads me to believe that there is "global optimization" going on that might go back and move things on earlier pages. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
