multiprocessor mode

Registered by artyom Le Sta

inkscape seriously there is no productivity.
Many paid analogues, such as xara and other commercial vector editors are able to involve more than one kernel of the processor for one copy of the editor.
Here it, unfortunately is not present.
History of a question I draw in inkscape for a long time and have faced a problem of productivity at use of the big number of objects with gradients and transparent elements.
Partially the question has been solved by splitting figure into layers, but it strongly does not help, as as a matter of fact, even breaking groups of objects on layers all of them remain active and demand drowing.
For an example my works can be found here:
1 http://www.gnome-look.org/content/show.php/gothic?content=107761PHPSESSID=961b3ac00ee201fc3377bea08532dc63
2 http://www.gnome-look.org/content/show.php/underworld?content=107199
3 http://www.gnome-look.org/content/show.php/inkscape_art?content=107198
4 http://www.gnome-look.org/content/show.php/(20-min+work)?content=107192
If to look an initial code, it is possible to see, that in some figures objects <path> represent lines from several coordinates, such as in 1,3,4 but if to consider figure 2, there it is visible, that objects <path> represent lists of a plenty of coordinates that slows down work with them and does not allow to archive figure with the greater percent of compression.
For the fast decision of the given problem I can give other works and tell what methods I drew them.
Yours faithfully, Artem Le Sta (Russia)

Blueprint information

Status:
Started
Approver:
None
Priority:
Low
Drafter:
None
Direction:
Approved
Assignee:
None
Definition:
Approved
Series goal:
Accepted for 0.91.x
Implementation:
Beta Available
Milestone target:
milestone icon 0.91
Started by
jazzynico

Whiteboard

2009-07-27 remi: I have a proposal for some multi threading based on some observations as a user of Inkscape.
I have made the following observations:
Moving around (also z-order) complex objects is very slow, as it seems that every time the position changes, everything in that area needs to be redrawn. Moving some images around however is much faster obviously.

So here is my proposal that I think is not too hard to implement:
Every object (also groups of objects) on the canvas maintains a cached version of itself (32bit) in the current resolution (zoom level), or rather it has a flag telling if it has a cached version of itself. For every operation that does invalidate the currently cached version of an object (zooming in, editing paths, etc.), all the affected objects will unset this flag. When updating (redrawing) the canvas, obviously Inkscape uses the cached versions which it handles just like images.
And now the thing that makes it multi threaded: I imagine a background thread which updates the caches of the objects, particularly when zooming in, one doesn't need the full resolution immediately, rather one wants immediate feedback. So a fast zoom on pixel level is enough and later the background thread does his work to create caches in the correct resolution. This can be extended to many simple operations like stretching and rotating.

Obviously there are many little things to be careful about (when is the cache invalid?) and of course the memory consumption will grow (so it should be an option, perhaps the maximum cache size is enough). But the benefits are huge as everyone that has ever moved a large object in Inkscape has to admit. Everything should feel snappier!

JazzyNico 2009-12-12
Multi-threading for blur operations is available in 0.48 in the preferences dialog. It is also implemented in 0.47, but you need to add the following line in preferences.xml manually:
<group
   numthreads="2"
   id="threading" />

tweenk 2011-06-20
Cairo renderer, which will be part of 0.49, has multithreading for all filters.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.