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.