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.
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.
