On Tue, Mar 15, 2011 at 11:53 AM, Jasper van de Gronde < th.v.d.gronde@...528...> wrote:

On 2011-03-13 15:52, Vladimir Savic wrote:

...

On Sun, 2011-03-13 at 15:37 +0100, the Adib wrote:

...

Is there any plan how we will speed-up performance in future. I mean:

• fast (visual) response to the user
• fast rendering

I know that we have:

• tiling the image into pieces to decrease user response time
• add OpenMP to filter functions

On the roadmap is conversion to cairo. But cairo does not render filters

at all.

...

...

I read that LLVM could speedup when generating the filter code .....

Maybe I misunderstood the concept behind filter rendering, but what about joining efforts with GEGL guys and using that library? I guess it will develop faster, both big apps that would use it (Inkscape and GIMP) will benefit from joined development, bugs will be fixed faster, etc. If I understand correctly, GIMP will use GEGL for pixel computations too and pass the resoult to cairo for drawing on canvas.

Could we please slow down just a bit. Basically someone has come and claimed, with some justification, that Inkscape is slow. It is, at least in some respects (no one files bugs for cases in which Inkscape performs marvelously). But we are working on performance issues continuously and I think pretty much any Inkscape developer knows at least a few things he would like to speed up.

As for getting some results, apart from some UI issues, which are important but which are not exactly my specialty, filters are probably the main cause of perceived slowness. I would like to make a couple of remarks about that. Inkscape mostly has implementations that are quite accurate, which often results in slightly worse performance than you might otherwise see.

May be Inkscape has accurate implementation but Inkscape document model is highly non effective. There is a simple comparing test. Just create 1000 rectangles, convert they into paths and measure memory usage in Inkscape, CorelDRAW and sK1. You will get approximately following numbers:

Cold start/With document Inkscape 0.48 62Mb/140Mb CorelDRAW X3 47Mb/63Mb sK1 0.9.1 51Mb/62Mb

So for the same drawing applications use: Inkscape 0.48 78Mb CorelDRAW X3 16Mb sK1 0.9.1 11Mb

The test file you can fetch here: http://sk1project.org/files/test1000_rects.svg

If you multiply objects (10k or more) you will see that Inkscape allocates 0.5Gb and more whereas Corel/sK1 uses less than 100Mb.

Actually similar issues are observed in all mature applications because initial architecture was not designed with all the implemented features. Gimp, Scribus, Inkscape and our sK1 already faced with this problem. CorelDRAW has passed this milestone in ver.10

I think you remember that we have presented Cairo-based rendering in sK1 on LGM2007 and since that time we have a lot of experience in this issue (whereas "cairofication" for Inkscape is upcoming feature). Using this experience I would say that "cairofication" doesn't resolve all Inkscape rendering problems because Cairo (at least current stable version) is not fast.

Concerning our project we have decided reimplementing sK1 and UniConvertor from scratch because the further development of just stuck in the architectural issues. We hope reporting results in our presentation on LGM2011, so I think we could discussing this in Montreal and it could be really useful for further Inkscape development.