Re: Cairo plans

[Jonas Hahnfeld]

Am Dienstag, dem 31.08.2021 um 11:34 +0200 schrieb Han-Wen Nienhuys:
> > 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 is the relevant metric here, because the MR enables lilypond-book
> processing. It is also relevant for development because our
> regtests/CI pipelinek are based on lilypond-book.

No, it's not: The timings you gave and the descriptions suggest that
you get that and that speedup for producing the HTML version of the
Notation Reference. This is not true because it already compiles all
.tely files, so you cannot extrapolate from one manual to the entirety.
The relevant metric for development is the time a complete 'make doc'
takes from start to end.

> > > 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.
> 
> I think it is a fair comparison, given that it's comparing a
> documented and shipping feature against an experimental feature. It
> would be unfair to dismiss the experimental feature due to bugs, but
> that's not what's happening here.
> 
> The SVG backend works roughly like the PS backend (run Scheme code
> that translates stencils to strings, which are dumped one by one to an
> output file), so I am willing to bet serious money that you can't get
> to perform faster than the PS backend, and by extension, the Cairo
> backend.

That's not what I was saying; the fact that you could make the SVG
backend up to 5x faster to match the PS backend (not exceed the Cairo
backend) makes it an unfair comparison right now.

> > > 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...).
> 
> I see your point, but consider the following: the PS backend
> represents 3500 fiddlesome Postscript and Scheme code, which is only
> exercised by us.

Yes, but it's battle-tested for how long?

> With the cairo solution, the complexity of rendering and font handling
> is moved to Cairo, which is much more widely used and better tested.

Disagreed strongly. If the addition of the Cairo backend has shown one
thing, then it's the fact we're running into serious problems for using
the less tested features of Cairo. It's probably working great for GUI
stuff, but the file output features seem to be severely lacking (memory
issues in the SVG and PNG backends, critical PDF features like links
only supported since recently, forward references not working until a
fix in master a few weeks ago, ...)

> We are only left with cairo.cc which is much more straightforward. It
> should be expected that the cairo solution takes comparatively little
> effort to stabilize.
> 
> > > * 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.
> 
> We can discuss this in detail later, but I think a major version bump
> is not warranted, as we're leaving the music input intact. For
> context, the 1.8 -> 2.0 transition happened when changed
> 
>   [(c4 c4)]
> 
> to
> 
>   c4[( c4])
> 
> which invalidated most .ly files, requiring manual vetting of the conversion.

I stay by the fact that changing the default backend is a fundamental
change that affects every single user of LilyPond. Going to 3.0 will
make this clearer than any release notes could ever be.

> 
> > 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
> 
> my feeling is that this state is actually pretty close now already.

Maybe it is, maybe it's not - impossible to tell for a backend that is
only a few weeks old. Why gamble on this?

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