Tim Roberts wrote:
>
> 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
>
>
Well, what if we divide the work using \bookpart {} or \score {}? Each
bookpart is separated by a page break, so it seems unlikely that there would
be cross-dependencies. I don't know how widespread usage of the syntax is,
but this is what I meant when I asked if there were any syntax changes that
could be used to implement multithreading.
--
View this message in context:
http://old.nabble.com/Sibelius-Software-UK-office-shuts-down-tp34245636p34262504.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user