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
