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.
I also think that SVG and GIS is not fully explored yet.
By the way, the current R-tree implementation in 2Geom is somewhat ugly, for example it exposes naked pointers to nodes, so I'd be hesitant to use it right now.
I'd be also hesitant to use it in Inkscape now. I wanted to have an r-tree working properly and then see what I can do. Some things I want to change, might cause change to the public part of the class.
I was actually planning to resume work on the trees (my semester ends with the end of the year). I'll need a visual testing and 2geoms toys are perfect for that.
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 rather 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 Inspector.
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 :)
__________________________________________________ �������������� Yahoo!; ���������� �� ���������� �������� (spam); �� Yahoo! Mail �������� ��� �������� ������ ��������� ���� ��� ����������� ��������� http://mail.yahoo.gr