Re: Cairo plans
Han-Wen Nienhuys writes: Hi, > Also: apologies to reviewers for the large Merge-Request. > Unfortunately, the backend code was quite convoluted, and I didn't see > a way except to just slash my way through it. refactoring along the > way. Sounds good, can I have a look at the patch set, do you have a git branch somewhere? I checked some projects for usage of \ps-command and it doesn't seem to bo popular. Losing that would have been my main concern, I think. Greetings, Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Guile 2 (was: Cairo plans)
> 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...). At the moment, I have trouble seeing how Guile 2 could be made to work well. The absence of error locations is a source of frustration. My understanding is that this is a design limitation of Guile 2 and later when interpreting code (as opposed to byte-compiling).
PATCHES - Countdown for August 30th
Hello, Here is the current patch countdown list. The next countdown will be on September 1st. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !891 font-kern.ly: Make regression test also check Emmentaler kerning - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/891 Countdown: !900 binaries: Minor updates to scripts - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/900 !899 cairo: ignore page links without page number - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/899 !898 Move utf-8-string special casing to stencil-interpret.cc - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/898 !896 More Moment cleaning - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/896 !895 framework-svg: remove output-classic-framework - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/895 !894 Drop framework-null, framework-scm - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/894 !893 Website maintenance - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/893 !888 Page stencil cleanups - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/888 Review: !901 cairo: fix FT_Face reference counting - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/901 New: No patches in New at this time. Waiting: !897 Draft: support cairo backend in lilypond-book - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/897 !892 Draft: Implement crop/preview/clip systems generically, supporting it for cairo. - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/892 !889 Draft: consolidate backend APIs - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/889 *** -- Regards James OpenPGP_0xAAC8D177A7F5A364.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Cairo plans
Jonas Hahnfeld via Discussions on LilyPond development writes: > 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... It's likely the workload for Wikimedia (though likely not via PDF) where performance is pretty relevant. -- David Kastrup
Re: Cairo plans
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
Re: Cairo plans
> Le 30 août 2021 à 10:16, Han-Wen Nienhuys a écrit : > > 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. 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 Wow, I'm impressed by the speedup. > If you want to reproduce this, download MR 897, and apply this to > force Cairo: > > diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py > index 2d5b9d76b9..33c570c9c6 100644 > --- a/scripts/lilypond-book.py > +++ b/scripts/lilypond-book.py > @@ -668,6 +668,7 @@ def main(): > > global_options.process_cmd += ( > ' '.join([' -I %s' % mkarg(p) for p in global_options.include_path]) > ++ ' -dbackend=cairo ' > + ' -daux-files ') > > global_options.formatter.process_options(global_options) > > for size comparison, notation.pdf for 2.22 is 6.7M 13M for this would be fine in my opinion. On contrary to HTML, which people browse directly on the website, PDF is usually saved and read locally -- isn't it? And few people actually use it compared to HTML. > For the final website, we anti-alias the images by generating them at > twice the resolution and then scaling them down. This seems > unnecessary with the Cairo output: the rendering already uses > antialiasing, and IMO, the plain Cairo output looks better than > antialiased GS (images attached). > > Open question is how to position Cairo output and what defaults we > should provide. > > * SVG. > > The current SVG backend is glacially slow, 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.) This is one of the reasons why I'm excited to see Cairo output. (CCing Johannes Feulner from scorio, who might be interested in having fonts embedded in SVG files.) > [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 > > The Cairo SVG files are larger, but that is because they also embed > the fonts used for texts, making the rendering exactly equal to the > PDF/PNG. > > * PS/EPS > > The Cairo backend doesn't support \ps-command. This is unavoidable, > and probably a feature rather than a bug. It also doesn't support > \eps-file, but that can be made to work: see > https://www.cairographics.org/manual/cairo-PostScript-Surfaces.html#eps) > > However, if Cairo is going to be the default, we should rather think > about PDF first (ie. embedding PDF images into the music). That's > possible, but we'd need to link in Poppler: > https://www.cairographics.org/cookbook/renderpdf/ What about PNG images? > The PS backend also has support for a couple of options that Cairo > doesn't have > > - embed-source-code > - font-ps-resdir > - gs-load-fonts > - gs-load-lily-fonts > - gs-never-embed-fonts > - music-font-encoding > - outline-bookmarks > > I think we can't support the options that tweak font loading, but do > we need to, if we generate our docs directly from PDF, and the result > is reasonably small? I agree with your reasoning. > Dropping Ghostscript altogether would let us delete ~5000 lines of > code, simplify runtime (no more subprocessing), our build (don't have > to build GS), 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? > > * when could/would we drop the PS backend altogether? Could we make Cairo the default in the next development release? We could make more noise than usual to get users to test it. I don't have an opinion as to when to retire the old backends. Wait on Cairo to get some testing exposure and let them go? The current SVG backend is barely usable
Re: Cairo plans
> 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. Great! > -rw-r--r--. 1 hanwen hanwen 13M Aug 30 08:45 out-www-cairo/en/notation.pdf This is still far too large IMHO. On my GNU/Linux box, the default documentation build (using gs 9.54 & extractpdfmark) produces a `notation.pdf` version that is less than 6MByte. > The current SVG backend is glacially slow, and has suffered from > rendering discrepancies. I propose we retire it ASAP to be > replaced by Cairo. I don't use SVG normally, but this sounds like a good plan, especially because of ... > The Cairo SVG files are larger, but that is because they also > embed the fonts used for texts, making the rendering exactly equal > to the PDF/PNG. ... this. > The PS backend also has support for a couple of options that Cairo > doesn't have > > - embed-source-code > - font-ps-resdir > - gs-load-fonts > - gs-load-lily-fonts > - gs-never-embed-fonts > - music-font-encoding > - outline-bookmarks > > I think we can't support the options that tweak font loading, but > do we need to, if we generate our docs directly from PDF, and the > result is reasonably small? This is the main question. IMHO, Cairo's output is definitely not small enough for large documents that embed zillions of small PDFs like LilyPond's Notation Reference PDF. What about retaining the PS backend but making Cairo the default? Maybe we can further convince the Cairo people to add a PDF output mode that doesn't embed fonts, leaving the final assembly to a better suited program (like gs). > Dropping Ghostscript altogether would let us delete ~5000 lines of > code, simplify runtime (no more subprocessing), our build (don't > have to build GS), and simplify our licensing story (no more > potential AGPL dependency). Right now, as discussed above, I favor not doing this. > Here are my questions: > > * when could/would we drop the SVG backend? ASAP, but I'm probably not qualified enough to make a decision here. > * when could/would we switch the default PS/PDF/PNG backend to > cairo? As the default: ASAP. Removing the old PDF backend: not now. > * when could/would we drop the PS backend altogether? As above: I suggest to retain it but making Cairo's PS output the default in case this is faster. On the other hand, I don't see any advantage to retain the PNG output given that Cairo produces exactly the same (according to your reports). Werner
Re: Cairo plans
+jan for real now. Also: apologies to reviewers for the large Merge-Request. Unfortunately, the backend code was quite convoluted, and I didn't see a way except to just slash my way through it. refactoring along the way. On Mon, Aug 30, 2021 at 10:16 AM Han-Wen Nienhuys wrote: > > 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. 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 > > If you want to reproduce this, download MR 897, and apply this to > force Cairo: > > diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py > index 2d5b9d76b9..33c570c9c6 100644 > --- a/scripts/lilypond-book.py > +++ b/scripts/lilypond-book.py > @@ -668,6 +668,7 @@ def main(): > > global_options.process_cmd += ( > ' '.join([' -I %s' % mkarg(p) for p in global_options.include_path]) > ++ ' -dbackend=cairo ' > + ' -daux-files ') > > global_options.formatter.process_options(global_options) > > for size comparison, notation.pdf for 2.22 is 6.7M > > For the final website, we anti-alias the images by generating them at > twice the resolution and then scaling them down. This seems > unnecessary with the Cairo output: the rendering already uses > antialiasing, and IMO, the plain Cairo output looks better than > antialiased GS (images attached). > > Open question is how to position Cairo output and what defaults we > should provide. > > * SVG. > > The current SVG backend is glacially slow, 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 > > The Cairo SVG files are larger, but that is because they also embed > the fonts used for texts, making the rendering exactly equal to the > PDF/PNG. > > * PS/EPS > > The Cairo backend doesn't support \ps-command. This is unavoidable, > and probably a feature rather than a bug. It also doesn't support > \eps-file, but that can be made to work: see > https://www.cairographics.org/manual/cairo-PostScript-Surfaces.html#eps) > > However, if Cairo is going to be the default, we should rather think > about PDF first (ie. embedding PDF images into the music). That's > possible, but we'd need to link in Poppler: > https://www.cairographics.org/cookbook/renderpdf/ > > The PS backend also has support for a couple of options that Cairo > doesn't have > > - embed-source-code > - font-ps-resdir > - gs-load-fonts > - gs-load-lily-fonts > - gs-never-embed-fonts > - music-font-encoding > - outline-bookmarks > > I think we can't support the options that tweak font loading, but do > we need to, if we generate our docs directly from PDF, and the result > is reasonably small? > > Dropping Ghostscript altogether would let us delete ~5000 lines of > code, simplify runtime (no more subprocessing), our build (don't have > to build GS), 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? > > * when could/would we drop the PS backend altogether? > > Thoughts? > > -- > Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Cairo plans
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. 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 If you want to reproduce this, download MR 897, and apply this to force Cairo: diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py index 2d5b9d76b9..33c570c9c6 100644 --- a/scripts/lilypond-book.py +++ b/scripts/lilypond-book.py @@ -668,6 +668,7 @@ def main(): global_options.process_cmd += ( ' '.join([' -I %s' % mkarg(p) for p in global_options.include_path]) ++ ' -dbackend=cairo ' + ' -daux-files ') global_options.formatter.process_options(global_options) for size comparison, notation.pdf for 2.22 is 6.7M For the final website, we anti-alias the images by generating them at twice the resolution and then scaling them down. This seems unnecessary with the Cairo output: the rendering already uses antialiasing, and IMO, the plain Cairo output looks better than antialiased GS (images attached). Open question is how to position Cairo output and what defaults we should provide. * SVG. The current SVG backend is glacially slow, 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 The Cairo SVG files are larger, but that is because they also embed the fonts used for texts, making the rendering exactly equal to the PDF/PNG. * PS/EPS The Cairo backend doesn't support \ps-command. This is unavoidable, and probably a feature rather than a bug. It also doesn't support \eps-file, but that can be made to work: see https://www.cairographics.org/manual/cairo-PostScript-Surfaces.html#eps) However, if Cairo is going to be the default, we should rather think about PDF first (ie. embedding PDF images into the music). That's possible, but we'd need to link in Poppler: https://www.cairographics.org/cookbook/renderpdf/ The PS backend also has support for a couple of options that Cairo doesn't have - embed-source-code - font-ps-resdir - gs-load-fonts - gs-load-lily-fonts - gs-never-embed-fonts - music-font-encoding - outline-bookmarks I think we can't support the options that tweak font loading, but do we need to, if we generate our docs directly from PDF, and the result is reasonably small? Dropping Ghostscript altogether would let us delete ~5000 lines of code, simplify runtime (no more subprocessing), our build (don't have to build GS), 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? * when could/would we drop the PS backend altogether? Thoughts? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
