Hi,

I'm currently mapping a fantasy world, and I have lots of different maps at different scales. The larger scale maps obviously exist within the area of the smaller scale ones. Some of the scales are sufficiently close together that there would be some merit in using some sort of inclusion to link the two files together. In particular, I have city maps at 1" to 120' scale, and local regional maps at a 1" to 1 mile scale. The shape of a city, if not the detail of its contents, is clearly visible on the smaller scale map. In an ideal world, I'd like this shape to be sucked in from the larger scale map so that it updates automatically... but if I do this naively I'm guessing that it will kill inkscape (a dozen towns with lots of detail embedded in a regional map is likely to kill it pretty quickly I imagine).

But let's say I manage my city document such that I put everything I might want to put into a smaller scale map (e.g.: a filled clone of the city walls to give an outline of the city shape + the major roads) into its own layer. Could I reference just that layer efficiently from the regional map without killing inkscape? How about I put a nested svg element into the parent map, defining the basic position for the nested section, and then xml:include the layer's <group> from the child map? I guess that might break a bunch of id references from the child map though... Anyone done anything like this? Am I on a hiding to nothing here or is there a good way of doing this sort of thing?

Cheers,

Lucian

Are these different scale maps in different files? Or are they on different layers of the same file? Or are you doing some fancy coding with SVG/XML?

In an ideal world, I'd like this shape to be sucked in from the larger scale map so that it updates automatically... but if I do this naively I'm guessing that it will kill inkscape (a dozen towns with lots of detail embedded in a regional map is likely to kill it pretty quickly I imagine).

How are you thinking this would happen? I guess a clone, linked inset/outset or linked pattern along path could accomplish that. But it sounds like you aren't thinking that way, at all. I just can't quite imagine how you would take the city outline from one map and apply it to the other map, if they are different files. Unless you're thinking some sort of script?

Hi Brynn,

Ok, so yeah, I'm thinking of something a bit fancier involving several files being pulled together. You should probably know that I used to write XML software for a living, so I'm trying to hack things based on my knowledge of XML standards....

SVG is of course built on top of XML. XML includes a feature called XInclude, which allows you to specify declarative inclusions of other files, including, I believe, fragments of other XML documents referenced using a fragment identifier. Most modern XML parsers will process XInclude automatically. I'm not expecting Inkscape to support creating the inclusions - I'll have to edit the XML very slightly to stick in the include directive - but I'd be a little bit surprised if it didn't manage to process them correctly, because I would have thought that they would use a standard XML parser under the covers rather than writing their own. I can't remember (if I ever knew) what behaviour is defined for compliant processors on serialising an XML infoset that contains content that was pulled in via xinclude.

Anyway this is a lot of talk and no action. Later on today I'll hack one of my svgs and see if Inkscape barfs on it. If it does I guess the only other possibility is an <image> element pointing at an svg file - but I'm not sure how much flexibility you have with exactly what you include in that case...

Lucian

Yeah, most of that is WAY beyond my understanding. I did help create this page on the Inkscape website, where basically all I did was search out some tutorials and other resources. https://inkscape.org/en/develop/about-svg/ So maybe you could find some help there. (I'm currently trying to write another new page about animation, but it's mostly kicking my butt, lol. And I just learned yesterday about google probably dropping SMIL support from Chrome. And since IE doesn't support it at all, Chrome dropping it will probably force Mozilla (Firefox) to drop it too. And that's a sad day for SVG animation, for sure!)

Hello,
Not all the SVG code is supported by Inkscape. It's better if you consult before:
- the Inkscape Guide
- Inkscape's wiki http://wiki.inkscape.org/wiki/index.php/Inkscape
- Inkscape.org https://inkscape.org/en/

- But my bet is for NO, In Inkscape isn't possible to link other SVGs

Hi,

the only thing that seems similarly working is using symbols, though I have doubts it would speed up the drawing.
(They "work" like clones as far as I know, which only makes the file size smaller, but won't improve rendering time.)

Blender's append function may be requested at launchpad.

Hi Lazur,

Yeah, I think you get the idea. As you say, I'm not sure that symbols are quite right, but perhaps I could bend them into doing what I was looking for. You say that it won't improve rendering time - this was one of my main questions about all this really: what is the relative importance to overall responsiveness of:

1. XML document size
2. Total number of objects defined, irrespective of visibility
3. Visible objects
4. Visible objects shown within the current canvas area (i.e. what's on screen now)
5. Objects whose detail is relevantly sized relatively to the current zoom level (i.e. do really really tiny objects get optimised out of the rendering early?)

I guess I was assuming that either (a) or (b) would be the most significant, but from what you are saying maybe this isn't right. If objects that are in hidden layers or even off screen have only a negligible performance impact, and document size in itself isn't *that* significant, then maybe I simply need to put everything in a massive document and be careful about the layers I switch on...

The linking/appending thing from Blender sounds like exactly what I'm talking about. I guess the other similar sort of thing would be something like Photoshop SmartObjects. I will stick something on launchpad at the end of this discussion if it seems like it might be a meaningful feature request; I can't imagine that it will get implemented any time soon, buy hey!

Cheers,

Lucian

Hi.

I'm still running the late 0.48 build. 0.91 has a new renderer, improved alot, but there are some problems with it too.
Like on win, the 64 bit crashes when you try to import a raster image -so it's suggested to use 32bit builds instead or find a pre 0.92 release.
With the new version, filtering, with the blurring is calculated by the gpu, which should speed things up.


But it's mostly try and error. Xml size doesn't matter that much. Similar example could be with png-s: a larger image compressed to the max needs smaller space, but more time to load. For that, one could expect it makes rendering slower at times.
Haven't experienced that, but some cases you can get too many heap sections, for similar reasons.

Recently cleaned up plots from matlab where cloning a parent object that had an alpha in fill and stroke caused both new and old versions to crawl (probably it was the stroke setting).
It was 1,6 MB, with ~4500 and 750 clones, and after removing "unnecessary" attributes, it could work fast.

Haven't checked, but my guess would be if these object weren't clones, having each their own style attributes, it would render much faster -as the renderer doesn't have to jump between the def section and the object all the time? Not sure about how it really works.


All in all, I'd guess it's D).
Especially if thinking of snapping, tiny objects don't get optimised out.
Also if there is a blurred object and you pan the view to an unaffected part of the canvas, it works faster.

Using layers to hide objects not in use is a common solution for large files.
Me? I just draw on the full range available, making a "mess". Which also has its limitation.

Good luck!

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.

100k nodes might sound like a lot, but e.g. I had a tree icon with 200 nodes which I naively sprayed over the canvas to produce a forest. I racked up a few hundred clones fairly quickly and the document slowed to a crawl FWIW unlinking the clones made no appreciable difference to the performance - it does seem to be purely about the rendering of the nodes rather than how they are represented in SVG.

I may still look into my linking ideas, but since document size seems to be much less relevant than node count, it probably isn't worth spending lots of time on

Cheers,

Lucian

Let's see if I can find a little tutorial I wrote for ways to deal with Inkscape's performance issues..... Here it is: viewtopic.php?f=6&t=12160 Maybe some of those ideas could help?

After a certian point, nothing helps, because the file is just too big. But in some cases, these tricks can be helpful.

Thanks for all the replies. Brynn - thanks for the link to the performance guidelines. For anyone coming to this thread later, here's a summary of what I've found here and through my own research:

• XInclude is not supported. In fact, it seems like almost no-one supports it (even Batik Squiggle)! I guess I got spoilt by using Xerces-J as an XML parser/processor, which supports basically everything the W3C publishes + a whole lot more besides!
• External entity references don't appear to work in SVG files in inkscape (Batik expands them correctly). It wouldn't really help me that much anyway since you can only include whole files
• External references, including to fragments do work in <use> elements (as of 0.91) See https://bugs.launchpad.net/inkscape/+bug/1269880. I suspect that there are mostly likely plenty of issues with this, particularly if the externally referenced fragment relies on other definitions elsewhere in its own document (gradients etc). There's no UI either.
• There's no concept of lazy-loading, so whatever you reference is going to slow down inkscape as much as if you'd put it in the same document.
• For large projects with wide scale brackets the most effective strategy is (irrespective of document organisation) ensuring that you keep stuff at different levels of detail in separate layers that you can switch on and off - the total visible node count seems to be the single biggest factor in performance if you aren't using lots of complex filters.