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
6 years, 11 months
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, 4 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
Removing ID attribute from group (XML editor) causes crash
by Bryan Hoyt | Brush Technology
While editing an Inkscape-created document, if I delete the ID attribute of
a group (or any other element, on further investigation) using the XML
editor, and then select that element in the visual editor, Inkscape crashes.
The ID in question is not referenced elsewhere in the document.
Is it valid SVG to have objects without IDs? It certainly seems like it
should be, particularly for hand-crafted SVG.
I can reproduce this trivially in Inkscape's trunk build from 22 Sep 2013
on a blank document with nothing but a plain rectangle.
- Bryan
--
Bryan Hoyt, *Software Developer* -- Brush Technology
*Ph:* +64 3 741 1204 *Mobile:* +64 21 238 7955
*Web:* brush.co.nz
9 years, 9 months
Recent change to ellipse to path conversion method?
by mathog
Earlier today I found one small bug related to images written to WMF
files and posted it in launchpad. But while working on that noticed
that there was also another binary change in the output that didn't
correspond to anything I could see in the images. A careful byte by
byte comparison of EMF and WMF output from the lp988601 and current
trunk branches showed that outside of my code there has been a change,
where the paths returned on ellipse to path conversions are not as they
once were. In emf-print.cpp in the print_simple_shape() routine a print
statement was added after the call to
pathv_to_linear_and_cubic_beziers() and the loop which adds up nodes,
lines, and curves. For the exact same ellipse (long axis aligned with
x, short with y, axis ratio about 2:1) this is what was found:
nodes lines curves
lp988601 5 0 4
trunk 9 0 8
They start at the same point, but differ from there. Tried it again
with perfect circles and got the same result.
The strange thing is that there is no change at all to the geom.cpp
file, where pathv_to_linear_and_cubic_beziers() is coded.
I also checked to see if anything similar could be seen in the GUI, and
it sort of could be. Select the ellipse, select "stroke to path", then
edit points. The points on the ellipse are in different places in the
two branches, and there are different numbers of points. For lp988602
there is one point on the end of each axis plus one point in roughly the
center of each quadrant. For trunk there are the same points on the ends
of the axis, plus two points within each quadrant, and these are
clustered towards the "sharp" ends of the ellipse.
Is this change intentional???
Thank you,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years, 9 months
Bug in Blend Modes, Please Help
by Martin Owens
Hey Devs,
Blocking bug lp:850992 [1] is proving impossible to get a handle on for
different devs who are not familiar with the blend code base and it's
resisting attempts to let us learn about it.
We could do with a heavy-hitting genius who hopefully knows something
about the blend modes for layers to figure this out. I'm betting it's a
single line fix when the little worm is rooted out.
To reproduce: Make a new layer with a blend mode other than normal.
Group any objects together.
Grouping fails to refresh, ungrouping works as expected. The area isn't
being cleared by the redraw method like the text bug (I checked), the
redraw is simply failing to happen at all. Tracing the update events is
what's causing some headaches since both upstream and downstream tracing
just seems to vanish.
Thanks for your help.
Best Regards, Martin Owens
[1] https://bugs.launchpad.net/inkscape/+bug/850992
9 years, 9 months
Devlibs, GTK3, latest TDM-GCC
by Johan Engelen
Hi all,
To the devlibs gurus: what is the status of GTK3 devlibs and, can we
try and make them compatible with the latest TDM-GCC? It'd be nice to be
able to use the latest gcc so we can use more C++11 in the future.
I'm not sure how much help can I can provide, but if supplied with
sufficiently detailed instructions, I don't mind compiling a lot.
Cheers,
Johan
9 years, 10 months
