2009/12/16 Krzysztof Kosiński:
Memory-and-disk indexing is not necessary for graphics applications.
We are not going to process GIS-like quantities of data, and even then
we can just use virtual memory.
No, *you* are not going :) Please don't speak for others :) With SVG
quickly evolving as native file format for GIS on the Internet (just
check the list of talks at SVG Open for last two years) there is no
reason why Inkscape couldn't be authoring tool.
Making heavy use of spatial indexing requires some significant
architectural changes, so it gives me another thought. Our current
double-tree architecture, where every element stores both its
"semantic" content (SVG) and "representation" content (XML) is
wasteful when it comes to memory, particularly when it comes to
embedded images. Storing only the semantic representation and
generating the XML representation on demand when saving could help
with the memory hog problem. It would also make easier e.g.
conditionally writing <svg:path> instead of <svg:rect> when the given
rectangle has markers, or using <svg:polyline> instead of <svg:path>
when a path has straight segments only. Abandoning the 1:1 XML-SP
correspondence could give us more flexibility, and promote better
coding (right now some places use XML tree calls where they should
evidently operate on the SP tree).
On the other hand, this approach is more bug-prone. It's not clear to
me now how to implement undo. We would most likely need to sacrifice
the editing capability of the XML Editor and turn it into an XML
Another area of potential improvement is the renderer. I heard from
others that migrating to Cairo could halve the total memory usage.
Well, whatever improves the situation, really :)