I committed the rendering cache work in revision 10579 of trunk.
If you encounter serious problems, you can turn off caching completely
by defining the environment variable _INKSCAPE_DISABLE_CACHE. For
example, run inkscape as:
$ _INKSCAPE_DISABLE_CACHE=1 inkscape
By default, each drawing will use up to 64 MB of memory for rendering
data. It can be set in the "Rendering" page of the preferences
(renamed from "Filters").
As usual, problem reports are welcome.
Revision 10589 removes all trace of libnr from Inkscape's code, which
was a major refactoring goal. This is a rather big change and might
break various things. Here is a short summary of the changes:
1. NRRect was replaced by Geom:Rect and Geom::OptRect as appropriate.
2. NRRectL was replaced by Geom::IntRect and Geom::OptIntRect as
appropriate. Note that the semantics of Geom::IntRect's contains()
function for points are slightly incorrect at this time, as max() will
be considered part of the rectangle even though it should not be. This
doesn't cause any obvious problems for now.
3. SPItem bounding box methods were rewritten. There are now methods
for bounding boxes in 3 different coordinate systems:
- visualBounds(), geometricBounds(), bounds() - bounds in the item's
own coord system
- desktopVisualBounds(), desktopGeometricBounds(), desktopBounds() -
bounds in desktop coordinate system (origin in bottom left, but
user-editable in the future)
- documentVisualBounds(), documentGeometricBounds(), documentBounds()
- bounds in SVG coordinate system
The "geometric" version returns the object bounding box as defined by
SVG (does not consider stroke, filters, clipping paths, masks, etc.).
The "visual" version considers all of this to return the bounds of the
area affected by the object. The legacy "approximate bbox" was
4. NRActiveObject was used only by SPAction. SPAction was converted to
GObject and NRActiveObject listeners were replaced by signals. Some
changes to verbs were made along the way.
5. nr-point-fns.h was used by some things in the gradient editor and
was replaced with code using Geom::LineSegment.
as the problem is still there I would propose following intermediate solution:
currently in the codebasis there is also an pdf import via
poppler-cairo. This one is disabled.
I would like to enable this as an additional pdf import possibility.
We have to decide later when it comes to the release which one to
integrate into the release.
so we can test in parallel the two options.
we have a big tester basis (compared to separate launchpad branch)
we get the possibility to switch to an tested poppler-internals
independent solution (while using poppler)
I there is no big NONO I will go forward and enable this within the next days.
attached the patch that is needed for this (tested on windows, should
work on Linux)
During this GSoC a LibreOffice student and her mentor implemented
support for VSD, binary Microsoft Visio documents, that Microsoft
never bothered to publish a specification on. The student managed to
do far more that she expected and ended up with a nice C++ library for
parsing VSD called libvisio that supports all geometric primitives,
formatted text, embedded stencils, all kinds of fills and strokes etc.
The long story is here:
Now, the short story is that the libvisio library (currently at
v0.0.7) has a tool called vsd2xhtml which converts VSD to SVG
documents and embeds them into XHTML documents. So it looks like it's
possible to write an extension for loading VSD directly to Inkscape.
Otherwise you have to do some text editing to get an SVG out of that
Howevere there is a party trick involved. Since VSD files are often
multipage, the convertor dumps every page into same XHTML file one by
one. So if someone decides to have a go at it, I think it would rather
be loader similar to our PDF loader which provides preview for letting
a user to choose a page for importing.
I've not been using Inkscape for a while lately.
Yesterday I made a new drawing and noted a considerable slowdown while
After some investigation, I found that this is mainly due to bounding box
update, i.e. while an object (or a group of objects, but a single one is
enough) is moved, its bounding box is drawn as a dashed rectangle around it;
when I start moving, the rectangle stays in its original position for a
while (and moving is ok), then if I stop moving or after a while it gets
updated in the new position and this takes ages! I can't work with such a
I've got a Pentium IV 3.2 GHz with 2 GB of RAM. I know it can be considered
pretty old a system, but I run all the software I need on it without any
problem. I feel that it should be fairly enough for an application like
Inkscape (I never use filters or other graphical features, only technical
drawing); and it was, up to few weeks ago.
I suspect that the bounding box is continuously recalculated but this is not
needed as the object cannot change while moving it; also, calculating the
bounding box for a single object should not be heavy at all.
So, should I start worrying for Inkscape requiring too much resources for me
in the near future (or even present) or can this be simply considered a bug?
I can easily trigger it by opening a new document, drawing a couple of
circles and a couple of rectangles, selecting all four objects and start
duplicating them with the spacebar: after a few duplications my CPU usage
goes very high and moving objects becomes a pain. It seems related to how
many objects are present in the drawing, which is a nonsense because moving
a single object should not depend on anything else but the object itself (I
tried with all snappings disabled too, of course).
Thanks and regards
View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p32606652.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Given that we are now parted from modevia, how about unloading builds
to graphicall which mostly hosts Blender builds? It already has an
Inkscape section that looks rather lonely.
So I have been doing a lot of work on the Import from OCAL dialog and I
have finally finished! I was wondering whether I could get some testing,
especially on some different platforms with different internet connections.
All you need to do is get my branch using:
bzr branch lp:~and471/inkscape/ocal-dialog-improvements
And then compile as usual. You will find the dialog in File > Import
So yeah, basically I want a lot of testing, to iron out any errors that
I have missed and also feedback on the stuff I have done. Then once that
is all done, I shall propose for merging into trunk.
A list of changes is below, as well as a link to screenshots of the new
== Changes ==
* UI Redesign (which includes)
- Altered the padding and packing of all widgets
- Added search entry with clear and search icons
- Added OCAL Logo overlay
- Put descriptions inline in list
- New preview widget that shows extra metadata
- New status widget to notify on errors/success etc.
- Dialog is now persistent (retains state)
- Better messages for the user
- Changed title/menuitem to 'Import Clip Art'
* Backend stuff (which includes)
- Use new GFile API instead of depreciated GNOMEVFS
- Use async methods so the UI isn't blocked
- Use smaller, thumbnail images in the preview widget (save on
bandwidth and increase speed)
- Implement cancelling of operations
- Put downloaded resources into one directory, from which we can
- Big cleanup in terms of code
I was wondering how powerstroke LPE was doing and whether we should
enable it, and just have come across a document on somewhat similar
thing called Advanced Outlines in Synfig Studio. I think some people
in this list will enjoy reading it :)
BTW, should we perhaps enable some of the LPEs in nightly PPA? Some
testing wouldn't hurt?
I have just checked in to my private Coons Patch Mesh Gradient branch,
code that allows the ability to create and edit mesh gradients. Warning:
This code is a real Hack. It is known to segfault and eat kittens for
lunch. It will need lots of reworking by real experts before one can
hope to see it in Inkscape trunk (as well as dealing with the issue that
meshes are not part of the SVG 1.2 standard... they have been accepted
as part of SVG 2.0 but that standard is along way from being appearing
even in a draft form).
What you can do with the code:
1. Create a simple one patch square mesh the size of an objects bounding
box. (Select the third button on the Gradient Tool-Tool Bar and the
double click the object.)
2. Drag corner nodes (diamonds).
3. Change color of corner nodes.
4. Drag handles (circles). There is no indication of what handle belongs
with which corner node or path so it can be confusing.
5. Divide a row or column of patches into two rows or columns. (Double
click on the lines connecting corner nodes. Double clicking elsewhere
may lead to a crash.) At the moment, the row or column is split down the
6. Save the mesh. The mesh is saved in the proposed SVG standard format
(highly likely to change).
7. Read in saved meshes.
Some of what is missing:
1. Ability to undo node moves/color changes.
2. Ability to merge two rows or columns into one or delete edge rows or
3. Ability to change paths between straight lines and Bezier curves.
Handles are shown even for straight lines.
4. Display of Bezier curves (they are shown as straight lines).
5. Stability (I did tell you it will segfault, didn't I?).
6. Sane coding.
7. Properly handling of gradient copying.
8. Auto-creation of conical gradients or other non-square gradient
9. Output to PS/PDF/PNG(?)
10. Update to current trunk.
You can check out the code at: