On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup <d...@gnu.org> wrote: > What does that mean? Mainly a viable migration strategy where we might > be able to drop catering for a whole lot of graphics programming > ourselves by introducing a dependency on Cairo. I am not overly
what "catering for graphic programming" mean? There is graphical programming, but a lot of it is done already. Moving towards a new library will be a big undertaking, so it could use more justification. > enthused about the programming quality of Cairo but LilyPond's quality > tends to be worse in the same departments gee, thanks. > and it's also hugely > inefficient due to using Scheme data structures and programming where > they are rather inappropriate and waste a humongous amount of resources. Show some numbers? How much is "humongous", and how much faster will it be with the snazzy new Cairo infrastructure? $ time ./out/bin/lilypond input/regression/mozart-hrn-3.ly GNU LilyPond 2.19.63 Processing `input/regression/mozart-hrn-3.ly' Parsing... Interpreting music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120] Preprocessing graphical objects... Interpreting music... Interpreting music... Interpreting music...[8][16][24][32][40][48] Preprocessing graphical objects... Interpreting music... Interpreting music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144] Preprocessing graphical objects... MIDI output to `mozart-hrn-3.midi'... MIDI output to `mozart-hrn-3-1.midi'... MIDI output to `mozart-hrn-3-2.midi'... Finding the ideal number of pages... Fitting music on 3 or 4 pages... Drawing systems... Layout output to `/tmp/lilypond-vi9Khi'... Converting to `mozart-hrn-3.pdf'... GS ps->pdf done: took 0.48000000 secs Deleting `/tmp/lilypond-vi9Khi'... PS done: took 0.60000000 secs Success: compilation successfully completed real 0m3.225s user 0m2.997s sys 0m0.209s Assuming you did everything optimally, you could shave off about 20% of the end-to-end runtime in this case. A simpler alternative could be to revisit how the PS is structured; it's hard to believe this is a good way to place text, for example: 5.3676 -165.1853 moveto /TeXGyreSchola-Regular 3.44335938 output-scale div selectfont 0.5804 0.0000 0.0000 /exclam 0.7512 0.0000 0.0000 /t 0.6146 0.0000 0.0000 /i 0.5463 0.0000 0.0000 /space Also, the PS could be written to a pipe, so GS runs in parallel to Lily. Some of the time in GS could overlap with LilyPond. > It would be a large amount of work to bring LilyPond's graphics > programming up to scratch. Moving to Cairo's data structures alone > would be quite advantageous and would likely speed up backend operations > significantly. which ones? In terms of graphics, the backend just does interval unions and offsets (floating point comparisions and additions) through the Stencil object. Unless you also restructure how objects are grouped, it's going to be similar. I can't recall seeing stencil evaluation ever figure prominently on a profile. > We might also be able to forego creating PostScript as an intermediate > stage to creating PDF and create bitmap formats without using PostScript > as well (again, this should really speed up things). that's the first realistic speed up; the PDF => PNG step seems expensive. > Drawbacks? Like other things, being on Guile-2.x would make for > synergies with existing projects (not least of all guile-cairo though I > haven't checked its suitability in general, with the new PDF-level > features, and possible compatibility with Guile-1: I think it supported > Guile-1 at some point of time). > > Of course, we have a number of other areas under construction anyway, > but I think that the graphics handling of LilyPond is so undercatered > for that our dearth of resources is more a reason for than against > starting on such a move. > > The first step would likely just involve moving to Cairo data structures > while keeping most of the current code except where the code would > duplicate Cairo API calls in a reasonably straightforward way. I would suggest trying make a GUILE binding of sorts for Cairo, adding that in parallel to existing GS support, and hacking untili you have feature parity. Then drop the GS support, and migrate the cairo data structures more towards the core of the program as needed. I strongly recommend being in a state where the Cairo support is half-merged but only half-working. timiing patch follows. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
diff --git a/scm/backend-library.scm b/scm/backend-library.scm index 8eec320..932d80c 100644 --- a/scm/backend-library.scm +++ b/scm/backend-library.scm @@ -21,6 +21,7 @@ (use-modules (scm ps-to-png) (scm paper-system) + (ice-9 format) (ice-9 optargs)) (define-public (ly:system command) @@ -73,7 +74,8 @@ (define-public (postscript->pdf paper-width paper-height base-name tmp-name is-eps) - (let* ((pdf-name (string-append base-name ".pdf")) + (let* ((start (get-internal-real-time)) + (pdf-name (string-append base-name ".pdf")) (*unspecified* (if #f #f)) (cmd (remove (lambda (x) (eq? x *unspecified*)) @@ -107,7 +109,9 @@ (string-append "-f" tmp-name))))) (ly:message (_ "Converting to `~a'...\n") pdf-name) - (ly:system cmd))) + (ly:system cmd) + (ly:message (ly:format "GS ps->pdf done: took ~f secs" (/ (- (get-internal-real-time) start) internal-time-units-per-second))) + )) (define-public (postscript->png resolution paper-width paper-height base-name tmp-name is-eps) diff --git a/scm/framework-ps.scm b/scm/framework-ps.scm index 2cd9b5e..5959d59 100644 --- a/scm/framework-ps.scm +++ b/scm/framework-ps.scm @@ -657,7 +657,8 @@ mark {ly~a_stream} /CLOSE pdfmark source-list (iota (length source-list)))))) (define-public (output-framework basename book scopes fields) - (let* ((port-tmp (make-tmpfile)) + (let* ((start (get-internal-real-time)) + (port-tmp (make-tmpfile)) (tmp-name (port-filename port-tmp)) (outputter (ly:make-paper-outputter port-tmp @@ -689,7 +690,11 @@ mark {ly~a_stream} /CLOSE pdfmark (display "%%Trailer\n%%EOF\n" port) (ly:outputter-close outputter) (postprocess-output book framework-ps-module (ly:output-formats) - basename tmp-name #f))) + basename tmp-name #f) + + (ly:message (ly:format "PS done: took ~f secs" (/ (- (get-internal-real-time) start) internal-time-units-per-second))) + + )) (define-public (dump-stencil-as-EPS paper dump-me filename load-fonts)
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel