Re: Using/requiring Cairo

[David Kastrup]

Just responding to a minor point:

Han-Wen Nienhuys <address@hidden> writes:

> I suppose that functions like
>
>   https://www.cairographics.org/manual/cairo-Paths.html#cairo-path-extents
>
> would be a boon.
>
> I was tickled to reply to your mail, because it was full of complaints
> ('hugely inefficient', 'humongous amount of resources'), without any
> measurements. Optimizing code without measuring is common pitfall, and
> I would not want you to fall in it.

I'm not really talking about "optimizing" here rather than "sanitizing"
or even better "throwing away".  I am aware that not all of Cairo is
what I would consider polished, but given the comparative manpower
interested in LilyPond and Cairo, I think it would leave us with less
trouble at our own doorstep if we can move to identifying problems with
Cairo rather than with LilyPond.

I don't see myself able to deal with all potential icky graphics code in
LilyPond, and I don't see anybody else stepping up either.  Shifting
some of the problems to Cairo is partly a copout, but partly it also
obliterates making decisions for how to deal with all the data shuffling
we are now doing: instead of reinventing what Cairo does with regard to
its representations, stealing them might save us additional work further
down the road.

> I would be much more supportive if you could show some numbers where
> memory/CPU is used right now, and could show some data how much Cairo
> would improve on things. It's quite possible that you are right, but
> then it should be easy to come up with some supporting data.

I'm at a loss here how to arrive at such data without doing the actual
work.

What isn't clear to me is how the font integration into Cairo surfaces
is going to work.  I guess that this will be the main problem for making
Cairo actually be responsible for producing output rather than serving
"merely" as an internal graphics toolkit.

-- 
David Kastrup