Figuring out when I should use the Vacuum Defs command is not very intuitive. In addition to knowing what features are stored as defs, you kind of have to keep track of how often objects using such features are modified or deleted. Or you can wait until your svg file is sufficiently bloated, or until Inkscape becomes sufficiently non-responsive. I've seen a few questions answered with "try vacuum defs", and suspect many others went unanswered as people gave up when their files became unmanageable because of unused defs.

I'm curious what people think about ways this might be improved. One option seems to be to have a separate thread incrementally looking for defs to be garbage collected. Hopefully this would keep the ui responsive. The main downside that I see, is that people may want to keep around defs that are not in fact being used at the moment, and this would likely get rid of them. I suppose there could be a special inkscape tag that could be added to defs to mark them as needing to be ignored by this vacuuming process. In fact a tag like this might be nice, even with the current vacuum defs command (haven't looked to see whether one already exists).

Another option, that may take more work to implement, would be to add a reference counting tag to defs. Every time an object is created, deleted, or modified... the differences in it's def references would have to be calculated and then the respective defs would need to be updated. I imagine this would require much more development work than the previous method. However, it seems like the more direct way to deal with this kind of problem; which at it heart sounds like a general resource management problem.

Both of these solutions will probably require a good bit of developer investment. Would the rest of you find this kind of feature as valuable as I would?

I do see the value of having some way to exclude things from the vacuum, especially gradients. In fact, I often keep tiny squares outside my page border to hold gradients, so that they don't get deleted when I click Vacuum Defs.

And it would also be helpful to know what kinds of things are storing "defs". All I really know as a "def" is an unused gradient. But I assume there are other things as well?

But as for some kind of "defs overload" indicator (I'm picturing a warning light on my car's dashboard, lol) I'm thinking that slow performance itself should be enough of a clue. I'd much rather see such features as an object manager, or better gradient management getting attention from the developers. But that's just my opinion.

I know about the game you're building (which is awesome, btw), but I'm curious what other ways that you use Inkscape, that would benefit from having automated def vacuuming? Are you just thinking of ways to keep responsiveness more stable?

I also know that in 0.49, we're all anticipating the new renderer, which will apparently, from what I understand, speed things up quite a bit. That doesn't mean that we will no longer have defs which need vacuuming. But my understanding is that we won't need to rely on Vacuum Defs as much as we do now. I'm not much for the technical side of Inkscape though, so I don't really know that.

brynn wrote:And it would also be helpful to know what kinds of things are storing "defs". All I really know as a "def" is an unused gradient. But I assume there are other things as well?

Filter definitions, masks, clip-paths, gradient transforms, patterns, pattern transforms, markers, symbols (supported, though not created by Inkscape), SVG fonts, paths for 'text put on path', hidden originals of clones, custom color swatches, … - and anything a user puts there (to be available as referenced object without being rendered visibly on-canvas). Hand-crafted SVG files or SVG files created with other applications also often store objects in the <defs> section (which are later referenced in the document e.g. with <use> (aka clones)).

Note: <defs> is not something private or proprietary to Inkscape - it's a regular SVG element:
SVG 1.1 > 5.3 Defining content for reuse, and the ‘defs’ element

LiquidAsh wrote:Both of these solutions will probably require a good bit of developer investment. Would the rest of you find this kind of feature as valuable as I would?

Inkscape knows custom tags to its own resources stored in the <defs> section - whether to auto-clean them when no longer referenced (gradients, filters) or on-demand ('File > Vacuum defs') (default). Resources can also be excluded (never purged) - e.g. custom color swatches (they are no longer purged by vacuum defs even if currently not referenced by any object).

Not sure what you are asking for (a resource manager as interface to comfortably handle referenced resource objects stored in the current document?), but as far as I know the requested underlying features are already present: Inkscape Wiki > Garbage collection

~suv wrote:...to auto-clean them when no longer referenced (gradients, filters)...

Are you saying that gradients and filters are already being automatically cleaned by Inkscape? Or is this a feature that needs to be turned on somehow? Here's what I tried (w/o success) to test this. In a new document (running Inkscape0.48 + devel r10744): I created a square with a linear gradient, copied it, and then pasted it several times (each copy has it's own gradient def). Then deleted the squares, but their gradients remained. Then tried saving the .svg (without any squares, only the lingering gradient defs), and after reopening this saved file the gradients remain(?).

The feature that I'm trying to describe would get rid of these extra defs as soon as the elements referencing them are deleted.

brynn wrote:I know about the game you're building (which is awesome, btw), but I'm curious what other ways that you use Inkscape, that would benefit from having automated def vacuuming?

I have several images that contain multiple frames of animation including state changes, and I set a clip on the image to define the size of one frame of animation. Copy-pasting these clipped images results in lots of extra clip defs (my main problem). Another one is the patterns... I have a brick image that I set as a pattern for the wall and floor rectangles. Then every time I copy-paste and then delete one of these walls, I end up with an extra pattern def.

Thanks for the info, ~suv