Jasper van de Gronde wrote: Hello! My name is Vangelis Katsikaros. I have worked a bit with Nathan Hurst (he was kind enough to provide feedback and guidance) in lib2geom on the direction of making Inkscape more efficient when a lot of "shapes" are in a file. Currently Inkscape looks *all* the shapes in order to find which are in the user's window (correct me if I am wrong). This is actually a spatial 2D query and has been solved efficiently in GIS database systems. Now, lib2geom offers a simple R-Tree solution, allowing for 2D spatial querying. There are still a couple of small tasks to do, and then we should go from memory-only indexing to memory-and-disk indexing (so the project isn't complete yet :) After we have an efficient way to find what must be rendered, the 2nd issue is rendering more efficiently. Nathan suggested that mipmaps could be incorporated in the R-Tree thus allowing to pre-render small shapes (related to the user's window). I still have more work to do (to finish the rtree) and then are many paths to follow. Any comments or thoughts would be interesting :) Regards Vangelis Katsikaros __________________________________________________ �������������� Yahoo!; ���������� �� ���������� �������� (spam); �� Yahoo! Mail �������� ��� �������� ������ ��������� ���� ��� ����������� ��������� http://mail.yahoo.gr

2009/7/2 Vangelis Katsikaros <vkatsikaros@...1244...>: 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. 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. 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. Regards, Krzysztof

Krzysztof Kosiński wrote: Not just memory, CPU cycles as well. Last time I checked path strings were updated after each operation on them, and this is definitely not a "free" operation. As for the UNDO issue that was raised, I don't know how it is done now, but I don't see why it would become truely more difficult (you just need to keep track of any changes you make).