Free advice from librsvg developer
Inkscape and SVG filters http://www.advogato.org/person/cinamod/diary.html?start=95
- Alan H.
P.S. Possibly the shortest email you'll ever see from me.
Quoting the article:
The filters all operate on pixel data, not SVG maths. As such, they're independant of Cairo, Libart, or whatever one wants to draw with.
But Cairo does operate on pixels, AFAIK. It renders vector data into pixels. So it makes a lot of sense to implement e.g. blurring directly in Cairo, not in Inkscape on bitmaps returned by Cairo.
Still, as I wrote, I can do quick-and-dirty blurring implementation even in our current renderer, once we have SVG support for filters.
it uses libart to draw
No, we don't use libart.
Sure, it might not be able to (currently) draw 10 gazillion polygons per second like Xara claims to do, but does Inkscape really need that level of performance?
Oh yes, we surely need as much performance as Xara has, and ideally more :)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Sat, 2006-01-14 at 03:33 -0400, bulia byak wrote:
Quoting the article:
The filters all operate on pixel data, not SVG maths. As such,
they're independant of Cairo, Libart, or whatever one wants to draw with.
But Cairo does operate on pixels, AFAIK. It renders vector data into pixels. So it makes a lot of sense to implement e.g. blurring directly in Cairo, not in Inkscape on bitmaps returned by Cairo.
Cairo doesn't provide facilities for blurring etc, per se. We will have to do the latter.
Same for the "byak compositing operator" which we use for handles and so forth.
-mental
On 1/14/06, MenTaLguY <mental@...3...> wrote:
Cairo doesn't provide facilities for blurring etc, per se. We will have to do the latter.
Same for the "byak compositing operator" which we use for handles and so forth.
Yes, but I was just saying that it _makes sense_ to do blurring in Cairo, even if it does not do it yet. After all, it's a pretty standard thing, specified in SVG, so I don't see why not implement it once and for all in Cairo. Same applies to SVG-specified composition modes (lighter, darker, inverse etc) - and these AFAIR were already present in Cairo last time I looked.
As for handles etc. with our own always-visible compositing, I see no reason at all to delegate that to Cairo. I think only the arena (i.e. actual SVG contents) should be rendered by Cairo, while all the auxiliary canvas things are best left as they are now. They are mostly done by simple pixel-flipping, without any AA, so they would not benefit from Cairo at all. The only exception is where the canvas items use our rendered for antialiased beziers - e.g. in the pen tool, but that would be relatively easy to switch from our renderer to Cairo calls.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
participants (3)
-
Alan Horkan -
bulia byak -
MenTaLguY