Author Topic: performance issues  (Read 3286 times)

May 31, 2016, 04:51:24 PM
Read 3286 times

brynn

  • Administrator

  • Offline
  • ******

  • 3,941
  • Gender
    Female

    Female
    • Inkscape Community
Hi Friends,
I was just looking at some of Lazur's new filters (http://forum.inkscapecommunity.com/index.php?topic=329.0).  Some of them are made in what I think of as an unusual way, meaning that they are based on a large number of objects (such as circles or rectangles, for example).  So I started wondering if those particular filters, which are based on the large number of objects, would tend to be "heavy" as far as Inkscape's performance.

Like if I have an Inkscape file with many paths, with 1000 and approaching 2000 nodes, Inkscape starts to slow down.  So I started wondering about a few different things, as far as Inkscape's performance. 

What if you were making an image of soap bubbles, and you had 100 circles or more, all different sizes.  Which is more likely to cause performance problems (on a computer with low ram)?

1 -- 100 circle shapes (zero nodes) or 100 circular paths (4 nodes each, 400 nodes)

2 -- Circles all filled with the same single gradient or circles filled with 100 different gradients

3 -- Circles filled with gradients or circles filled with any filter

4 -- Circles filled with typical filter (simple blur) or circles filled with one of Lazurs's filters (which are based on many objects) (such as http://forum.inkscapecommunity.com/index.php?topic=329.msg2489#msg2489)

It's probably a "non-issue" but I just want to understand better  :)

Thanks!
  • Inkscape version 0.92.3
  • Windows 7 Pro, 64-bit
Inkscape Tutorials (and manuals)                      Inkscape Community Gallery                        Inkscape for Cutting Design                     



"Be ashamed to die until you have won some victory for humanity" - Horace Mann                       

May 31, 2016, 05:46:44 PM
Reply #1

Lazur

  • IC Mentor

  • Offline
  • ******
  • Inkscape Filters Wizard

  • 1,154
  • Gender
    Male

    Male
Testing, testing, and testing.
All it needs.

Speaking of the mentioned filters, that was very simple.
Just a colormatrix filter primitive added with hue rotate mode, each of them from 10, 20, ... 350/360 rotations. That's 11 simple filters applied on a rectangle of the same gradient fill.

In general the necessary rendering processing power for filters is related to the filter's complexity and the filtered area/number of pixels to compute.
If you zoom out, complex blurring can be rendered quickly.

So then filter complexity can be sorted out of this kind of comparison.


Qiestion is more of the comparing of storing data in the def section of the file or elsewhere and rendering time.

As far as I could see it too much of the unused defs can lead to crash. Maybe related to garbage collectors too.
My guess is it is not so good idea to make thousands of used defs either.
Remember this produced rendering glitches originally, rendered through browsers. May be fixed now unfortunately.

This topic had a similar problem of improving performance on a large file, whether it is possible linking/embedding/appending parts of another drawing.

Quote (selected)
So I've played around a little bit and it seems like the primary thing that matters to Inkscape performance is the total number of nodes that are visible anywhere in the current document. (I.e. (c) from above). On my machine (1.7 Ghz Core i5 4GB Intel HD Graphics 3000 384 MB - admittedly not the fastest) once you get up to about 10k nodes in visible layers you really start to notice that every operation on any object has a bit of lag. Nothing *too* serious, but noticeable. Once you get to 100k nodes, it's pretty frustrating - moving an object happens in 0.5 second "frames". Whether any of the stuff is actually displayed within the bounds of your current window seems largely irrelevant. As you point out, however, adding filters into the equation changes this - blurring etc does seem to be based on what is currently visible. That worries me less because I can easily work with filters off most of the time.



  • Circle elements -available since 0.91- take less code to describe in the file, resulting in a smaller document but don't think there would be a significant difference in rendering time.
  • 1 single gradient means less gradient defs, easier rendering theoretically but since all gradient filled objects are linked to the def section and have the same amount of transformations, there shouldn't be a notable difference in rendering time, although if each object has individual gradient defs it will be a larger file.
  • filled with gradient vs filter applied
    What kind of gradient and what kind of filter, and at which zoom level?
    Filter defs can be a few lines vs gradients can also have alot of steps and lot of codes in the def section.
    If blurring or convolution matrix is added and you zoom in, the gradient renders faster.
    Performance issue? Depends on, but my guess is that not so many are into making crazy filters when zoomed in.
  • Blur is not a simple filter, probably the most resource heavy filter primitive alone.
    Offset filter and compositing are "low weight" while this one
    or this or this one are heavyweight bastards.

May 31, 2016, 08:33:30 PM
Reply #2

brynn

  • Administrator

  • Offline
  • ******

  • 3,941
  • Gender
    Female

    Female
    • Inkscape Community
Well, I was hoping it could be discussed without making test cases (especially 100 circles with gradients and filters and different kind of filters, etc.).  But maybe I will get around to it.

But does it all come down to the defs?  Nothing else contributes to the problem?  I think more than defs, it's overall data.  Because with large number of nodes, I don't think is defs, although maybe I'm wrong.  But I think the data for nodes isn't in defs section.  I don't know if that's right or wrong.    Also, at some point, I think it's with filters, where the processor gets involved.  Is it processing data with the filters?  Or something else?

Yeah, looking in XML Editor for a file with simple paths (a LOT paths) the nodes data is not in defs section.  This is the first time I've noticed 'perspective id = perspective10'.  It seems new to me, but I don't look at XML much.

And for imported raster images, that's not in defs either, is it?  No, looks like that comes under "data" too.

Maybe I'll try to test, we'll see.
  • Inkscape version 0.92.3
  • Windows 7 Pro, 64-bit
Inkscape Tutorials (and manuals)                      Inkscape Community Gallery                        Inkscape for Cutting Design                     



"Be ashamed to die until you have won some victory for humanity" - Horace Mann                       

June 16, 2016, 05:09:42 AM
Reply #3

Dillerkind

  • IC Mentor

  • Offline
  • ******

  • 131
  • Gender
    Male

    Male
    • Svenson's Bunte Bilderbude
But does it all come down to the defs?  Nothing else contributes to the problem?  I think more than defs, it's overall data.  Because with large number of nodes, I don't think is defs, although maybe I'm wrong.  But I think the data for nodes isn't in defs section.
Usually, nodes aren't stored in the defs section but inside their paths. Though iirc there are cases when node data is stored in defs, e.g. clip- or mask-paths.

I can't say much about filters but have a little addition to gradients: re-using gradient definitions definitely helps cut down on file-size and make things less cluttered (think the dropdown-menu in the gradient tool's settings bar). I prefer this method. Usually I have maybe 5-10 gradient definitions to which all the gradients in the document are linked. At some point though performance does degrade and the program seems to become more unstable, resulting in more frequent crashes. I can't say for sure that it's linked to heavily re-using gradient definitions though in a few recent pics where I didn't use gradients, I had zero application crashes whereas in my "normal" works with dozens or even hundreds of grads Inkscape tends to crash more often, the further I get with the image. Also, maybe it's just me but I think stacking large shapes with radial gradients can at some point result in worse performance too.

June 16, 2016, 06:37:34 PM
Reply #4

brynn

  • Administrator

  • Offline
  • ******

  • 3,941
  • Gender
    Female

    Female
    • Inkscape Community
Thanks for your comments.

In the past talking about performance issues, I would be comparing the file size/weight with the offending object or features, to the file size/weight without the objects.  But now, I'm thinking of comparing the feature which cause performance issues to each other (instead of with or without).

It's this filter which has me interested.  It seems like the coffee cup is made of many circles (with some blur or gradient), all organized together.  But it's offset primitives of the original circular path.  So now I think, do those offsets have any weight?  And I'm also curious about filters which don't have any blur.  I guess most filters have some kind of blur, but I wonder about other kinds.

Well, it's on my to-do list.  Still near the bottom, at this point.  But it will make it to the top eventually.  So I'll make some test files, and post them here, for those who might be curious -- and hopefully my curiosity will be satisfied too  :D
  • Inkscape version 0.92.3
  • Windows 7 Pro, 64-bit
Inkscape Tutorials (and manuals)                      Inkscape Community Gallery                        Inkscape for Cutting Design                     



"Be ashamed to die until you have won some victory for humanity" - Horace Mann