Inkscape gains performance boost

Inkscape gains performance boost

Inkscape, the free vector graphics editor for Linux, Windows and Mac, has always been know as somewhat slow when it comes to complex drawings with lots of objects and/or SVG filters.

Luckily quite dramatic changes are finally coming to address this particular issue.

Cairo, OpenMP and SVG filters

A Google Summer of Code 2010 project by Krzysztof Kosiński is part of the main development branch now, with two major changes: porting of rendering to Cairo and threaded rendering of SVG filters using OpenMP.

Cairo is an increasingly popular library for rendering 2D vector graphics. Porting Inkscape's rendering to Cairo results in up to 2x rendering speed boost for shapes with flat and gradient fills. Additionally some rendering bugs and limitations have been fixed. For instance, there is now no limit for rendering gradients at large zoom level, even though gradient related fixes demand Cairo 1.11.2 and newer.

For threaded rendering of SVG Filters Krzysztof used a rather popular OpenMP technology. If you have a computer with a multicore CPU, you will definitely notice a rendering boost. Rendering of all supported SVG filter primitives is threaded.

Again, this part of changes is already available in main development branch, and Ubuntu 11.04 and 11.10 alpha users can use PPA with nightly builds, with Windows and Mac builds expected shortly. However the good news don't end here.

Caching

This year Krzysztof works on another GSoC project that is also related to Inkscape's performance. The code is already available in a new gsoc-caching branch. What's special about it?

The big change is that now actual SVG documents are rendered separately from things like selection cue, mouse pointer etc. That means working on complex illustration is really faster, path highlighting is much faster, drawing selection cue above embedded bitmap is faster as well, and so on and so forth. And if you disable automatic update of paths rendering for the Node tool, editing pahs with SVG filters applied will be considerably faster as well.

While working on that Krzysztof had to work around some weird things in Cairo regarding rendering of clipping path. This coincidentally led to improvements in nested clips rendering. Oh, and you can also use text objects as clipping paths now.

If you are brave enough to compile source code, you can fetch the new branch using this very command:

$ bzr branch lp:~tweenk/inkscape/gsoc-caching

No builds for testing are ready yet, but fear not: merging the second project to main development branch is likely to happen around August/September. Both GSoC projects are destined to be part of 0.49 release. While not scheduled yet, it's expected around winter 2011/2012.

Update: the day after publishing this article Krzysztof merged his changes from gsoc-caching branch into trunk (main development branch). Expect the awesomeness in the next PPA build or compile trunk from source code.

Was it useful? There's more:

12 Responses. Comments closed for this entry.

  1. JimmyVolatile 14 July 2011 at 1:54 pm

    Excellent! Can’t wait ‘til August. (Actually, I’m going to attempt building it from source since it went so well the last time) :)

  2. fetching gsoc-caching branch now!:D

  3. @tobaj Good luck :)

  4. @prokoudine
    I’m usign it right now. Just playing with simple icons (modifying this awesome theme: http://gnome-look.org/content/show.php/area.o43+SVG+Icon+theme?content=101979) so I can’t get much benefit in performance out of Krzysztof’s patches.

    Does his branch include the Cairo and OpenMP changes as well? Asking only because the last revision in it is 10360 while in the master branch it’s 10450.

    Also speaking of overall Inkscape performance I wish that the interface responsiveness was better. This has been always a bigger issue for me than rendering/drawing performance, especially when I have more instances of Inkscape running.

  5. I’m not sure when he merged changes from trunk the last time.

  6. From what bzr log tells me, the latest commit was a merge…
    ————————————-
    revno: 10360 [merge]
    committer: Krzysztof Kosiński <tweenk.pl@gmail.com>
    ...
    message:
      Merge from trunk to pull in fix for LP #806105
    ————————————-
    ... but I understand it was only one patch to fix a particular issue.

    Prior to that the last ‘full’ merge from trunk was on 06/07:
    ————————————-
    revno: 10352 [merge]
    committer: Krzysztof Kosiński <tweenk.pl@gmail.com>
    ..
    message:
      Merge from trunk
    ————————————-

    So I don’t think the changes in question have been merged. And I don’t think they would come from gsoc-caching branch originally as the name of the branch suggests it’s only for a certain (different) stuff..

  7. Dear Moderators,
    In above comment I couldn’t get the Polish letter to be displayed correctly (in the middle of Krzysztof’s surname). I can type it while editing but after posting it gets replaced with the character code. Please advise how to fix it. I care to use the proper letter instead of changing to ‘n’ as I’m Polish as well..

  8. Cairo rendering was merged to trunk from a different branch indeed. I’ll ask Krzysztof about merging these changes to his gsoc-caching branch.

    Codepages are horribly broken in PHP Fusion. This wll and as soon as we finish moving to a new CMS that uses UTF-8 all the way.

  9. \o/ TuT \o/

    Krzysiu, wielkie dzieki! :D Eh polskie znaki nie dzialaja :D

  10. “Good news, eeveryone” (c) Futurama

    Krzysztof has just merged first batch of changes from gsoc-caching into trunk. Hence changes will be available in unstable PPA any time now.

  11. Very good news indeed! I’ve just seen the commit in trunk. So now I can either compile from that branch with all other updates or just wait for new packages from PPA.

    ... actually NO: I can’t wait!

    BTW: your set of emots sucks :)

  12. Added the trunk PPA to check it out. The tools definitely feel more responsive, but the rendering of the drawing seems about the same. Always great to see progress.