
On Mon, Jan 22, 2007 at 10:58:21PM -0400, bulia byak wrote:
On 1/22/07, Bryce Harrington <bryce@...961...> wrote:
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.
What's wrong with sp-canvas? It's well tested and is being increasingly optimized, and its overhead is minimal anyway compared to the renderer. Yet replacing the canvas will be much more difficult than the renderer, because the canvas and SPCanvasItems are the foundation of a lot of our codebase. So I'm not in favor of replacing it, unless some very good reasons are given. We just need a much faster way to convert shapes into pixels, but from that point on we can handle it just fine.
You removed too much of my original email. One of the options (e) is indeed to retain our existing canvas and update it to work with Cairo.
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
If we do stick with what we have, another option to consider is breaking it out into a stand-alone library atop Cairo, that others can use independently of Inkscape. We've had many RFE's opened requesting this.
Bryce