Cairo does the job fairly fast and you can set up multithreading in

Edit/Preferences/Rendering/

I set the number of threads to 8 some days ago and I was a bit disappointed to see no enhancement at reboot. Just forgot I set inkscape preferences file to be read-only. Fool.

Now it's better :)

Basically, each filter primitive constitutes a very expensive copy of the

image.

Yes know that. By the way, is there any chart about CPU consumption of each primitive ? (say for 1px wide). I would say lighting is the more CPU intensive, am I right ?

(if you're really interested, I'd recommend searching the archives).

Is there any other way to search the archives than the sourceforge web interface ? The UI is crappy and inefficient (or maybe I missed something obvious)

all these problems are non-trivial to solve.

Maybe it lacks at least one trivial optimisation. It looks like Inkscape render all primitives even if they're not "connected" to output. Exemple Create new filter. Add a Fill => rendering is lightning fast. Add 50 blur stages with a 100 px radius => it should be slower or way slower or ssslllloooowwwweeerrr (depending on your hardware). Logical. Move the fill at the last stage of pipeline. Still slow. It shouldn't. It's uneccesary to compute any blur stage at all.

You'll ask why the hell do you add unnecessary stages ? When I design filter I often ask myself "what will it looks like if I disconnect these block of 5 primitives " As adding primitive is very slow with the current interface (*) I don't remove the block but I only disconnect it. As time goes by there are more and more dead blocks and I sometimes forget to remove them. I'm not 100% sure but I think I saw dead blocks in filters fitting with inkscape

* any news about this blueprint ? http://wiki.inkscape.org/wiki/index.php/SpecFilterEditorUI No ? So I should think about buying a new monitor. Mine (1920*1200) is too small for designing filters. lol