2007/1/22, Bryce Harrington <bryce@...961... >:

On Mon, Jan 22, 2007 at 07:07:10PM -0700, Joshua A. Andler wrote:
> No one will disagree about Cairo's current speed.

Although, it'd help to have some tangible benchmarks to go by.  But in
general I don't think there's disagreement on this point.

> If we are doing other refactoring though, it wouldn't hurt for us to
> look into what needs to be done for an eventual renderer
> replacement. Do we really want to solely maintain a renderer forever
> when we can get other improvements for free with a shared library?

As I understand things, Cairo in and of itself isn't enough - it just
renders stuff.  What we need in addition to Cairo is a Gtk canvas layer,
that provides an interactive way of interfacing to the renderer.

Presently there are a couple Gtk+ Cairo canvas libs - Papyrus and
GooCanvas.  I've only briefly looked at them and neither seems
particularly mature.  I couldn't say whether they are developing in a
direction that will eventually support what we need, nor is it clear
which of the two would be the better option to adopt.  But I think it
would be worthwhile for someone to give them a deeper evaluation.

> I know that the main goal of the current dev cycle of Cairo is
> performance improvement (last time I checked there was major work going
> on for tessellation). Additionally, given that our renderer is faster,
> perhaps our devs could help improve the speed of Cairo (as we're
> pitching in for PDF improvement).

Fred did much of the coding for our renderer, and it's been a long time
since we've seen him.  Mental is active on the Cairo list already.
njh always was focused more on the algorithmic aspects, that he's now
encapsulating into 2geom.  pjrm has been busy with family stuff.  So,
we're currently a bit shy on active renderer-level expertise ourselves.

> I'm not advocating a switch anytime soon, I'm just thinking it would
> smart to develop a plan at the time other things are being refactored.
> This way if the Cairo guys figure out some super-speed voodoo and we
> really want to switch, it will be that much easier (and potentially faster).

Agreed.

Well like Mental says, the refactoring work is going to be a major
prerequisite; without it, any sort of architectural change like this is
going to be much more painful than it'd be with it.

Aside from that, I think a canvas analysis may be the next major step.
Perhaps this could even be done in parallel.  Basically, we'd need to
decide if we want to:

a) Go with goocanvas
         or papyrus
         or some other 3rd party lib
b) Adapt our existing canvas layer to work with Cairo
c) Create a new canvas layer
d) Some combination of the above
e) Stick with what we have

However, it's not likely we'll be able to get all the refactoring work
done quickly, so it may be premature to make canvas decisions right
yet.

Bryce

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel