© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
@Turbo
> How about Inkscape doing multithreading
Inkscape already did multi-threading and has been doing so for a long time, simply because it is GTK application. Taking advantage of threading implementations such as OpenMP or even GLib's own threading mechanism does not increase the amount of memory available to the application, nor in this case is it memory bottlenecks that are making Inkscape slower.
> and x64 so it can use all the RAM available ??
If you are on a amd64 GNU/Linux distribution, have compiled Inkscape with the system compiler on OS X 10.7 or greater, or have used 64-bit Windoze/MSYS to compile Inkscape, there is a high likelihood that your binary is already running in 64-bit mode. 64-bit is also not a magic bullet to make the program faster -- using 64-bit programs can make register transfers faster as they can be done in increments of 8 bytes instead of 4 bytes, but this is not where Inkscape is slow.
Rather, Inkscape is slow because it unnecessarily pipes out signals during long-running events (such as dragging nodes or gradient handles, or selecting thousands of objects on the canvas), and does not have a well structured framework for coordinating the events that it emits. I am working on more of this in the experimental branch -- selecting lots of nodes is several times faster, working with hundreds of gradients is faster, the renderer is slightly faster, and so on. This is again reiteration of what Jon Cruz mentioned earlier, about slowing down emission to speed up Inkscape.