I've been thinking about our Cairoification plans today, and I think we might be much better off incorporating Xara's rendering engine instead.
Two main reasons:
- Xara provides a lot of stuff that we would otherwise have to write ourselves atop Cairo (e.g. gaussian blur)
- Xara is considerably faster
I don't want to simply borrow code from Xara, though -- ideally, I'd like to componentize the relevent portions of Xara so that both projects could use and jointly maintain them, as a sort of "common pot". Xara would benefit from this, since (in the long term) to fully implement the SVG specification we'd need to contribute additional capabilities which Xara Extreme could then exploit.
To make the task managable, we'd want to approach this on a bottom-up basis: begin with the lowest-level components (e.g. the rasterizer), and work our way up to ultimately componentizing and incorporating the retained-mode graphics layer. The eventual goal would be to replace both livarot and NRArena with components shared with Xara.
I'm going to start seriously looking into the technical aspects of this once I'm done with the current spate of layers work (probably post-0.44/0.45).
-mental
On 3/23/06, MenTaLguY <mental@...3...> wrote:
- Xara provides a lot of stuff that we would otherwise have to write
ourselves atop Cairo (e.g. gaussian blur)
Are you sure Cairo has/will have no blur? I heard it's committed to supporting everyhing that's in SVG, and this is a standard SVG filter.
- Xara is considerably faster
But if Cairo gets Xara renderer, it will be just as fast.
Anyway, so far it's premature, since Xara's renderer is the part which is not opensourced yet (it remains a binary lib in their source tarball).
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Fri, 24 Mar 2006 00:05:58 -0400, "bulia byak" <buliabyak@...400...> wrote:
On 3/23/06, MenTaLguY <mental@...3...> wrote:
- Xara provides a lot of stuff that we would otherwise have to write
ourselves atop Cairo (e.g. gaussian blur)
Are you sure Cairo has/will have no blur? I heard it's committed to supporting everyhing that's in SVG, and this is a standard SVG filter.
Cairo implements a simple rendering model which happens to overlap with a subset of SVG's rendering model (both loosely patterned after PDF's model).
I did understand that Carl and company are interested in making it generally suited to rendering SVG (and it is), but my understanding was also that stuff like image processing (i.e. SVG filters) was outside its scope. I'll double-check on the Cairo list, though.
- Xara is considerably faster
But if Cairo gets Xara renderer, it will be just as fast.
True, although that's not a given yet. Cairo isn't GPLed, after all, so they would have to negotiate the release of the code under the (significantly more liberal) Cairo license.
Anyway, the Cairo API would expose only a subset of the needed functionality. IIRC I had a discussion with Xara folks on this list a while back, and they indicated one of the difficulties would be that Cairo's API only allows for expressing a subset of what they need.
At minimum, the Xara code would have to be split into pieces: one "below" Cairo, as a Cairo backend, and one "above" Cairo, built on top of it.
Anyway, so far it's premature, since Xara's renderer is the part which is not opensourced yet (it remains a binary lib in their source tarball).
Ahh... I hadn't looked at that yet, honestly. But, like I said, this would be in the post-0.44/0.45 timeframe anyway. Hopefully that would be sorted out by then.
-mental
On Fri, 24 Mar 2006 9:26:47 -0500, MenTaLguY <mental@...3...> wrote:
True, although that's not a given yet. Cairo isn't GPLed, after all, so they would have to negotiate the release of the code under the (significantly more liberal) Cairo license.
Actually, as I realized for my other mail, Cairo's dual LGPL/MPL now, which is not as big a change from GPL as Cairo's old MIT license would have been.
-mental
On 3/23/06, MenTaLguY <mental@...3...> wrote:
- Xara provides a lot of stuff that we would otherwise have to write
ourselves atop Cairo (e.g. gaussian blur)
Actually, I don't know how it's structured inside, but on the UI level Xara has NO simple gaussian blur. That was one of my major gripes with them. Instead they only have "feathering" (which is applying a blurred transparency mask made from the object itself) and drop shadows, i.e. some things built on blur but not blur itself.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Fri, 24 Mar 2006 13:55:03 -0400, "bulia byak" <buliabyak@...400...> wrote:
On 3/23/06, MenTaLguY <mental@...3...> wrote:
- Xara provides a lot of stuff that we would otherwise have to write
ourselves atop Cairo (e.g. gaussian blur)
Actually, I don't know how it's structured inside, but on the UI level Xara has NO simple gaussian blur. That was one of my major gripes with them. Instead they only have "feathering" (which is applying a blurred transparency mask made from the object itself) and drop shadows, i.e. some things built on blur but not blur itself.
Hmm, that's a bit disappointing. There's probably usable code there, but I imagine it requires some refactoring then.
Well, that's why I post these things. Y'all do a good job of sanity-checking me.
-mental
Hey,
Have you ever considered using AGG as the rendering engine in Inkscape? AGG (AntiGrain Geometry, http://www.antigrain.com/) is a very high quality and fast C++ 2D graphics engine and there's even an SVG renderer based on it (http://www.antigrain.com/svg/index.html).
Cairo seems to be very slow in all the benchmarks so I don't think it's very suitable. You should take a look at the AGG examples and join the AGG mailing list for more info.
-- Juha Varkki
On Fri, 24 Mar 2006 21:07:29 +0200, "Juha Varkki" <admin@...1218...> wrote:
Hey,
Have you ever considered using AGG as the rendering engine in Inkscape? AGG (AntiGrain Geometry, http://www.antigrain.com/) is a very high quality and fast C++ 2D graphics engine and there's even an SVG renderer based on it (http://www.antigrain.com/svg/index.html).
We've considered it in the past. One disadvantage it has relative to Cairo is that its architecture doesn't appear to easily permit hardware acceleration, which is going to become more important in the future. A related advantage is that (as others have pointed out) the pluggable backends allow Cairo to output Postscript and PDF directly.
From a performance standpoint, generally when people are benchmarking Cairo, they are benchmarking its software backend, which is (from what I've seen of the code) pretty horribly unoptimized. So, while I'd be reluctant to use AGG directly, it might be an interesting exercise to write an AGG backend for Cairo...
-mental
participants (3)
-
bulia byak -
Juha Varkki -
MenTaLguY