Re: Cairo plans

[Jonas Hahnfeld]

Am Montag, dem 30.08.2021 um 10:16 +0200 schrieb Han-Wen Nienhuys:
> With MR 897, I have been able to run the doc build through
> Cairo. Results are very encouraging: the build is faster, while the
> resulting PDF file is smaller.

As Werner remarked, only due to not using extractpdfmark.

> Also, I think we could skip emitting EPS files for Cairo altogether, which 
> would be another small speedup.
> 
> In timings below, I started with an empty out-www/ and lybook-db/ directory,
> 
> PS backend (gs-api, no extractpdfmark)
> 
>     $ time make -j4 out=www out-www/en/notation.pdf
> 
>     real 1m44.958s
>     user 5m26.919s
>     sys 0m14.347s
> 
>     $ time make -j4 out=www out-www/en/notation-big-page.html
>     real 2m15.521s
>     user 7m34.088s
>     sys 0m19.567s
> 
>     $ ls -lh  out-www-trad/en/notation.pdf
>     -rw-r--r--. 1 hanwen hanwen 38M Aug 30 08:48 out-www-trad/en/notation.pdf
> 
> Cairo
> 
>     $ time make -j4 out=www out-www/en/notation.pdf
>     real 1m20.922s
>     user 4m4.571s
>     sys 0m9.407s
> 
>    $ time make -j4 out=www out-www/en/notation-big-page.html
>     real 1m39.933s
>     user 5m33.227s
>     sys 0m12.100s
> 
>     $ ls -lh  out-www-cairo/en/notation.pdf
>     -rw-r--r--. 1 hanwen hanwen 13M Aug 30 08:45 out-www-cairo/en/notation.pdf

Giving timing for a single HTML file is a bit dubious because it
requires processing all .tely files for cross-references. For the
influence of Cairo, you really want to compare the time it takes to run
lilypond-book to get a single .texi file. However, I'd like to remark
that generating zillions of tiny snippets is not really the kind of
things users tend to do...

> [...]
> 
> Open question is how to position Cairo output and what defaults we
> should provide.
> 
> * SVG.
> 
>   The current SVG backend is glacially slow

IIRC the reason is the widespread use of regexes for matching glyph
nodes. I think this could be done better, and comparing speed isn't
really fair until then.

> and has suffered from
>   rendering discrepancies. I propose we retire it ASAP to be
>   replaced by Cairo. The only feature missing is the 'svg-woff option;
>   not sure how important that is? (CC'ing Jan who implemented this.)
> 
>     [hanwen@fedora lilypond]$ time lilypond --svg
> input/regression/les-nereides.ly
>     GNU LilyPond 2.23.4
>     ..
>     real 0m1.662s
>     [hanwen@fedora lilypond]$ time lilypond  --svg -dbackend=cairo
> input/regression/les-nereides.ly
>     GNU LilyPond 2.23.4
>     ....
>     real 0m0.728s
> 
> [...]
> 
> Dropping Ghostscript altogether would let us delete ~5000 lines of
> code, simplify runtime (no more subprocessing), our build (don't have
> to build GS),

Quite the opposite: GS is *really* simple to build with no additional
dependencies; Cairo on the other hand at least requires libpng and
pixman.

> and simplify our licensing story (no more potential AGPL dependency).
> 
> Here are my questions:
> 
> * when could/would we drop the SVG backend?
> 
> * when could/would we switch the default PS/PDF/PNG backend to cairo?

From my current understanding of missing features, the amount of
testing the backend can have received (or rather cannot, due to
novelty), and the nature of bugs that are found (both in Cairo itself
and the integration in LilyPond), I don't think the backend is
currently in a state to be used by default. I would highly prefer to
not mix switching the default backend with switching to Guile 2.2 that
will already be disruptive enough (yes, it's going slower than I had
hoped...).

> * when could/would we drop the PS backend altogether?

I would say that this step requires going to LilyPond 3.0, along with
removing all the features and commands that cannot be implemented in
the Cairo backend, or that we don't want to.

I would propose the following: For the next stable release (whenever
that will be), it would be good to have the Cairo backend mature enough
that it can be shipped as a "preview" in the official builds (that will
hopefully use the new system by then). Then we could explicitly call
out widespread testing and announce that the next version will be
LilyPond 3.0, that it will switch to Cairo and users are encouraged to
test their scores with the preview option, and what features are
expected to be removed. Then we could do the switch in the next
development cycle and have enough time to shake out all the issues that
crop up.

Regards
Jonas

signature.asc
Description: This is a digitally signed message part