Re: Cairo

[Han-Wen Nienhuys]

On Sat, Jun 26, 2021 at 10:52 PM Jonas Hahnfeld via Discussions on
LilyPond development <lilypond-devel@gnu.org> wrote:
>
> Am Samstag, dem 26.06.2021 um 19:43 +0000 schrieb Werner LEMBERG:
> > > No, it's definitely too soon for a merge request.  A few
> > > stencils->cairo procedures need to be added, a bit of error
> > > handling
> > > (to prevent at least possible segfaults) is necessary, a bit of
> > > logical cleanup is desirable, etc.
> >
> > Well, you can start the commit message of the merge request with
> > 'WIP:'; this prevents execution of the CI stuff, AFAIK.
>
> No, it doesn't. There are ways to not run CI jobs for a particular
> commit, but I don't really see the point just for the sake of pushing
> the current demonstrator into a merge request.
>
> May I instead propose an incremental approach? Implementing a fully
> capable Cairo backend probably won't happen in a single MR, and making
> it the default will be even further down the road. I think for a first
> step the Cairo stuff needs to be optional and in a proper backend, not
> hacked into the current Postscript code. Then others can test, missing
> features can be added over time, and it's possible to evaluate further
> steps.

I agree. Creating a new backend is actually fairly simple. Just copy
framework-ps.scm to framework-cairo.scm. That should be enough to get
you support for -dbackend=cairo. If you want, you can also copy
output-ps.scm, but that's not strictly necessary (anything that
populates the dispatch alist for the paper-outputter will work.)

I had a quick look at the C++ code. The global variables are a bit
concerning. As a start, you could put them into

  class Cairo_context {
     RefPtr<Cairo::Context> cr;
     ...
  }

this struct will then later be a natural candidate to create a smob
from. However, I wonder why you want to go through Scheme in the first
place, as the output mechanism (Cairo) lives in C++, while steering
the output goes through C++ as well (see paper-outputter.cc).

For the prototype, I think it would be better to insert the Cairo data
(Cairo::Context etc.) into Paper_outputter itself. Then, you can
intercept the Stencils directly in Paper_outputter::output_scheme.
Once that works, we can figure out something with inheritance to
factor out the cairo-specific code.

Hope this helps,

Han-Wen


>
> Jonas



-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen