Re: Using/requiring Cairo

[Han-Wen Nienhuys]

On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup <address@hidden> 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 - address@hidden - http://www.xs4all.nl/~hanwen

timing.patch
Description: Text Data