performance problems and possible remedies?
by Yale Zhang
Hi. I'm using Inkscape to author a comic and the slow speed for certain
things is very annoying. I'm already have OpenMP turned on and using 4
cores.
1. *large blurs are slow* - I'm an expert with writing SIMD code, so I was
thinking about vectorizing the Gaussian IIR filter with SIMD intrinsics,
even though it's harder than for a FIR. But I noticed there isn't any SIMD
code in Inkscape so does that mean it's something to avoid.
I'm pretty sure no current compiler is smart enough to vectorize it, and
besides, Inkscape is compiled with -O2, meaning -ftree-vectorize isn't on
by default.
2. *when there's a large image (raster based) background - scrolling in a
zoomed region is very slow*
I compiled the latest 0.49 code with GCC profiling and it shows this:
33.98 22.47 22.47 exp2l
21.29 36.55 14.08 log2l
17.57 48.17 11.62 pow
7.12 52.88 4.71 658 0.01 0.01
ink_cairo_surface_srgb_to_linear(_cairo_surface*)
6.72 57.32 4.44 563 0.01 0.01
ink_cairo_surface_linear_to_srgb(_cairo_surface*)
5.51 60.96 3.64 1216 0.00 0.00
Inkscape::Filters::FilterGaussian::~FilterGaussian()
5.23 64.42 3.46 internal_modf
0.59 64.81 0.39 _mcount_private
0.41 65.08 0.27 __fentry__
0.12 65.16 0.08 GC_mark_from
0.09 65.22 0.06 5579 0.00 0.00
Geom::parse_svg_path(char const*, Geom::SVGPathSink&)
0.06 65.26 0.04 35320 0.00 0.00
bounds_exact_transformed(std::vector<Geom::Path,
std::allocator<Geom::Path> > const&, Geom::Affine const&)
0.06 65.30 0.04 8 0.01 0.01
convert_pixbuf_normal_to_argb32(_GdkPixbuf*)
0.05 65.33 0.03 885444 0.00 0.00
std::vector<Geom::Linear, std::allocator<Geom::Linear>
>::_M_fill_insert(__gnu_cxx::__normal_iterator<Geom::Linear*,
std::vector<Geom::Linear, std::allocator<Geom::Linear> > >, unsigned long
long, Geom::Linear const&)
The cost is absolutely dominated by ink_cairo_surface_srgb_to_linear() and
ink_cairo_surface_linear_to_srgb(). My first instinct was to optimize
those 2 functions, but then I thought why are those even being called every
time I scroll through the image?
Why not convert the images up front to linear and stay that way in memory?
If that can't be done, then my optimization approach is:
1. replace ink_cairo_surface_srgb_to_linear() with a simple 3rd degree
polynomial approximation (0.902590573087882 - 0.010238759806148x +
0.002825455367280x^2 + 0.000004414767235x^3) and vectorize with SSE
intrinsics. The approximation was calculated by minimizing the square error
(maxError = 0.313) over the range [10, 255]. For x < 10, it uses simple
scaling.
2. replace ink_surface_linear_to_srgb() with a vectorized implementation
of pow(). Unlike srgb_to_linear(), a low degree polynomial can't be used
due to the curve having larger high order derivatives. An alternative would
be piece wise, low order polynomials.
The main question I have is what degree of accuracy is desired? Certainly,
it doesn't need double precision pow() since the input is only 8 bits! Is
+- 0.5 from the true value (before quantization) OK or do people depend on
getting pixel perfect results?
UJ
7 years
non-Unicode symbol fonts do not work on Windows. Bug 165665. Do we need the flag USE_PANGO_WIN32 ?
by Alvin Penner
ref : https://bugs.launchpad.net/inkscape/+bug/165665
I believe this bug can be fixed by disabling the flag USE_PANGO_WIN32 in
line 19 of src/libnrtype/FontFactory.h. When I do this on Windows XP, I gain
about 35 new fonts. Not all of these new fonts are useable, but the most
interesting ones, such as CommercialPi, Symbol, Technic, Webdings,
Wingdings, MonoType Sorts, TechnicLite are working well, both in Inkscape
and in IE9.
This is a Windows-specific bug which hides symbol fonts, and does not
occur in Gimp 2.6 on Win XP. As far as I can tell, the Gimp source code does
not contain any analogue or equivalent of the flag USE_PANGO_WIN32.
Would there be any objection if I disable this flag, or does it serve a
specific purpose that is essential?
tia
- Alvin Penner
--
View this message in context: http://old.nabble.com/non-Unicode-symbol-fonts-do-not-work-on-Windows.-Bu...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
8 years, 4 months
Improved gears extension
by Jürgen Weigert
Just saw braingram's rack gear extension coming in. Nice work! Thank you.
But that reminds me that I also have a small contribution to share. Here is
an enhanced version of the gears plugin, please also consider this for
future inclusion
git@...2977...:jnweiger/inkscape-extensions-gears-dev.git
cheers, JW-
9 years, 5 months
Mac OS X Mountain Lion x86_64 packaging of 0.48.4
by Valerio Aimale
Hello,
I am not an official packager, but I was eager to have an updated
version of Inkscape for Mac OS X and I noticed that nobody is packaging
the new version.
I've packaged it for Mountain Lion and x86_64. It should be considered a
beta packaging. I've packaged from version 0.48+devel r12005
You can download it at:
https://rapidshare.com/files/3885726044/Inkscape_MountainLion_x86_64.dmg
The Mac Os X packaging infrastructure in the source tree is a bit
ancient. Things I've noticed:
- configure.ac uses syntax that is not conforming anymore with
autoconf/automake/authohear 1.13. Going forward that should be updated.
- the scripts osx-build.sh os-app.sh needs update for the newest Xcode
versions. they don't work out of the box.
- the dylib base relocation infrastructure needed to be rewritten
- the Platypus-derived ScriptExec executable might not be needed anymore
- in this version, the app bundle executes the sh script directly.
Features:
- The version I packaged runs gtk-2.0+quartz. It does not need
X11/Xquartz anymore to run. This is the direction GIMP has gone to as well.
- It uses the same theme as GIMP. I think it's a good consistency
decision, and it's the theme that looks best on Mtn Lion.
If somebody want to try and report problems, I'd appreciate it
Valerio
9 years, 7 months
Devlibs 46 too slow
by LucaDC
After updating to devlibs r46 moving objects around becomes too slow in my
system and Inkscape is nearly unusable even for simple drawings.
Open a new document, draw a rectangle and move it around: the lag is huge.
Even changings of the cursor when hovering over it are updated with delays
of 1 s or more. Moving and snapping guides (not to guides), on the other
hand, is very fast.
My system is a Pentium 4, 3,2 GHz, 2 Gb RAM with Windows XP SP3.
Reverting to devlibs r45 (trunk 12277) gives back the previous (acceptable)
response time. I know my system is old, but with r45 it's fine for all my
needs.
Isn't this terrible performance drop avoidable? Inkscape is already not a
jaguar...
Regards.
Luca
--
View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
9 years, 9 months
Mac OS X Build 0.48.4 RC1
by Valerio Aimale
This is a good build that is close to being a release:
For Mountain Lion
http://rapidshare.com/files/4204947016/Inkscape-r0.48.4-r9943-10.8%2B-x86...
For Lion:
http://rapidshare.com/files/3505176415/Inkscape-r0.48.4-r9943-10.7%2B-x86...
- the menu should be all working but the "Open Recent" submenu. No
matter which item is selected, the top open is always opened. This is a
bug between gtk/gtk_recent_menu_manager() and gtk-mac-integration. Needs
more analysis, not an easy fix.
- Quit, About and Preferences menu items moved under the app menu.
- python should be fully working now on Lion and Mountain Lion
- uniconvertor/sk1libs installed and fixed
The sk1libs/utilsfs.py line
return ['/']
really should be
return ['/System/Library/Fonts', '/Library/Fonts',
os.path.expanduser("~/Library/Fonts")]
- no more noise on the terminal stderr
- bunch of improvements and changes in the build system
10 years
Which container used for path nodes?
by Shriramana Sharma
I'm not sure where in the source tree to look for this, so I'll ask this here.
What container does Inkscape use to store the nodes of its paths? I
mean, a drawing program would often use (in STL terminology)
push_back, pop_back, insert and erase. (I don't think push_front would
often be needed.) The contained value type would probably contain a
few flags in addition to the x,y coordinates. So I'm curious what
container you people chose to cater to these requirements.
Thanks.
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
10 years, 2 months
Automating an Inkscape workflow
by Eric Greveson
Hi all,
This is my first post to the Inkscape developer list, so - hello! I've been
using Inkscape for various server-side operations as part of a project I'm
currently working on, and I believe I've run into the limits of the
existing scripting / extensions capability. However, I'll describe my
requirements, problem, current solution, and proposed improvements, and see
what you think.
The requirements: I wish to perform "deep subtraction" of one pre-defined
path (let's call it P) from an SVG - that is, to perform a Boolean
difference operation against each path within the SVG (let's call them S1,
S2, ... Sn) such that a 'hole' (in the shape of my path) is punched through
all of the SVG layers.
The problem: Inkscape Boolean difference operations operate on pairs of
paths, such that the uppermost of the two paths is subtracted from the
lower path. The operation may only be performed on selections of two paths
(i.e. you can't select 10 paths and have the uppermost path be subtracted
from all of the lower 9 simultaneously).
My current solution: The obvious approach is to simply perform the Boolean
operation once for each path in the SVG, cloning the path P to allow it to
be subtracted again each time. That is:
Create P
Perform S1 - P
Create P
Perform S2 - P
...
Create P
Perform Sn - P
This results in every path in the SVG having P subtracted, which is exactly
what I want. To implement the "Create P" operation, I've written a Python
extension that inserts a <path> element into the document (i.e. I can
create P by simply executing this extension script within Inkscape). To
perform a difference operation, I can use the (somewhat maligned?) command
line interface with
--select <id of S1> --select <id of P> --verb SelectionDiff
and I can automatically call my "create P" extension with --verb
<my.extension.name.noprefs>.
I therefore just have to ensure all paths in the source SVG have IDs,
extract these IDs, and then chain a big long command line together to
perform all the creation, selection, and Boolean subtractions. I accomplish
the ID extraction with my own Python script (running independently from
Inkscape, simply using normal XML parsing code) and get that script to
concoct a long string of command-line arguments.
The obvious problem here is that for files with more than a few IDs, I run
into the command-line argument length limit. I have hacked around this by
editing Inkscape's main.cpp file and allowing it to take --select / --verb
arguments from a text file instead (note that --shell does not do the same
thing - it still requires all commands to be on one shell-line, and the
line length has a limit). Clearly this is not particularly clever, although
it does work - it means I have my own special build of Inkscape and it uses
an extremely clunky "scripting" mechanism.
The proposed improvements: I have looked at alternative solutions and have
come up with the following:
- I could edit the C++ code for Boolean operations such that the
difference operation works on more than one path. However this is very
specific to my problem, and it's likely that I'll want to perform other
Inkscape automation tasks in future that don't use the Boolean ops.
- There appeared to be some DBus API at one point but it seems to have
fizzled out (
http://comments.gmane.org/gmane.comp.graphics.inkscape.devel/40384 was a
useful discussion) - and DBus isn't really ideal for this kind of scripting
anyway.
- Allow further scripting of Inkscape through a Python API - this is my
preferred solution, and also, it seems, several other peoples'. The major
drawback is that this is likely to be more coding work. However, I have a
suggestion that will solve my immediate problem and potentially be useful
to others. If I wrote a Python API that allowed Inkscape extension scripts
to execute Inkscape verbs and selections, then I could perform all of the
necessary operations inside a single Python extension. I could then run the
extension from the command line in the usual way (--verb
my.extension.name.noprefs). Initially this might take the form of an extra
couple of functions on the Python inkex.Effect object:
- do_verb(verb_name)
- select_ids(id_list)
Then any Inkscape Effect extensions can execute verbs and modify selections
as they see fit.
Does this sound like a good plan? Any other input? I'm happy to write the
code for this if you think it would be generally useful, it seems a bit
limiting at the moment that effects essentially have to modify the raw XML
document themselves to get any useful work done. If the "do_verb" function
was modified to take an argument list (along with the appropriate C++
functions), then it would allow for even richer GUI-free interaction (e.g.
automation of "Save As" operations and so on).
Thanks for reading such a long message,
Eric
10 years, 3 months
