[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using/requiring Cairo

From: David Kastrup
Subject: Re: Using/requiring Cairo
Date: Sun, 25 Jun 2017 14:05:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Just responding to a minor point:

Han-Wen Nienhuys <address@hidden> writes:

> I suppose that functions like
> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]