Re: [Inkscape-devel] [Inkscape-user] Slow performance on 4.5 MB file [SOLVED]
And please be sure to file a bug/feature request at http://bugs.launchpad.net/inkscape/
In the end there will obviously always be cases where Inkscape is too slow, but Inkscape could most definitely be faster in some cases. And just locking/unlocking the layer should (from an intuitive standpoint) NOT cause such a big pause.
Dave M G wrote:
Donn,
Thank you for responding.
I have long moaned that "Nodes mean slow" :( I have a fast machine and 2gigs of RAM. It makes no difference. I think it's all the looping through those long lists of nodes....
You are doomed. Unless you can simplify or chop-up your comic page into frames and assemble them later in Gimp.
Okay. While it's a little disappointing that there isn't a way to optimize the file for better performance, it's good to know that at least I'm not doing something wrong.
I'll export the paths into a PNG and handle the colouring in Photoshop or GIMP. It means committing to rasterizing the images sooner in my process than I had hoped, but hey, life is full of compromises.
Jasper van de Gronde wrote:
And please be sure to file a bug/feature request at http://bugs.launchpad.net/inkscape/
In the end there will obviously always be cases where Inkscape is too slow, but Inkscape could most definitely be faster in some cases. And just locking/unlocking the layer should (from an intuitive standpoint) NOT cause such a big pause.
Dave M G wrote:
Donn,
Thank you for responding.
I have long moaned that "Nodes mean slow" :( I have a fast machine and 2gigs of RAM. It makes no difference. I think it's all the looping through those long lists of nodes....
You are doomed. Unless you can simplify or chop-up your comic page into frames and assemble them later in Gimp.
Okay. While it's a little disappointing that there isn't a way to optimize the file for better performance, it's good to know that at least I'm not doing something wrong.
I'll export the paths into a PNG and handle the colouring in Photoshop or GIMP. It means committing to rasterizing the images sooner in my process than I had hoped, but hey, life is full of compromises.
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
On Thu, Jul 2, 2009 at 2:04 PM, Vangelis Katsikaros 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 :)
The only comment here would be: when do we have this in Inkscape? :D
A quick test the sK1 team did recently with a file containing 20K circles. The use of memory is:
sK1 - 145 Mb CorelDRAW X3 - 210 Mb Inkscape - >1000 Mb
Alexandre
2009/7/2 Vangelis Katsikaros <vkatsikaros@...1244...>:
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 :)
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
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 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 :)
Alexandre
Krzysztof Kosiński wrote:
2009/7/2 Vangelis Katsikaros <vkatsikaros@...1244...>: ... 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, ...
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).
W dniu 16 grudnia 2009 20:16 użytkownik Jasper van de Gronde <th.v.d.gronde@...528...> napisał:
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).
Right now there are 5 event structures (attribute change, content change, child order change, child creation, child deletion) that are stored as a singly-linked list in response to subtree observer notifications on the root node. There's also a special event structure that marks an undo point. There are some unit tests that verify that undoing the events by walking the list and performing the opposite changes until the next undo point is found yields the original tree.
The main incentive to doing this on the XML tree rather than the SP tree is that the number of event types is limited. Doing this in this way on the SP tree would be cumbersome - every attribute in every class would need a corresponding event structure.
Regards, Krzysztof
participants (4)
-
Alexandre Prokoudine -
Jasper van de Gronde -
Krzysztof Kosiński -
Vangelis Katsikaros