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, 12 months
Create releases more regularly
by Sebastian Zartner
Hi there,
I initially asked at
inkscapeforum.com<http://www.inkscapeforum.com/viewtopic.php?f=22&t=15755&p=63224>and
was told to better post my request to this mailing list.
I wonder if it wouldn't be possible to create releases more regularly.
Currently there are many months or even years between each release of
Inkscape.
Bug fixes should get out more quickly and it should be possible to try out
new features of upcoming versions. Most users don't have the possibility to
build Inkscape by their own, so they have to wait for the next release.
Unfortunately the provided development downloads are not synchronized,
hosted on different third-party web sites and out of date (currently
especially the Windows version).
So I suggest to create a (more or less) fixed fast release cycle for normal
releases (e.g. every two or three months) and periodically (e.g. every one
or two weeks) create alpha versions.
Alpha versions should be built (maybe even automatically) for all supported
OSes and hosted directly on inkscape.org.
Sebastian
7 years, 7 months
Re: [Inkscape-devel] Devlibs 46 too slow
by Mark Titchener
I tried your modified build with an NVidia Quadro 1000M on Windows 7 and it
seemed okay to me.
> Le Jeudi 21 novembre 2013 9h09, Nicolas Dufour <nicoduf@...48...> a ?crit
> :
> > I'm still investigating the issue, and just found out that the computers
> I
> > used to reproduced the bug were all using an Intel GPU. Tests with an
> nvidia
> > GeForce 210 (GT218) show no slowness at all.
>
> Could some Windows users help me? I'd like to confirm the slowness only
> affects Intel graphics cards. Could you test a modified Inkscape binary
> (from ftp://download.tuxfamily.org/inkscape/inkscape-12282-cairo-1.12.8.7z),
> give your graphic card model and tell me if it's slow or not? IMHO it could
> be a blocker for 0.49 on Windows.
>
>
7 years, 7 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
Making inkscape usable in valgrind grumble
by mathog
Hi all,
In order to find memory leaks, some types of access violations, and the
use of uninitialized variables I depend on valgrind. The problem is
that valgrind is barely usable with Inkscape. The output on even the
most minimal session (open, type a few letters, format them, close) runs
to just under 500K lines and takes 5 minutes to complete. Some of this
may be because garbage collection must be turned off in order to use
valgrind. That is:
export _INKSCAPE_GC=disable;
valgrind .... src/inkscape
There is no choice in that though, because if it is not done valgrind
crashes when it tries to run inkscape. (Ubuntu 12.10.4, 32 bit, current
Trunk). There is a libgc.supp in the top of the distribution, but it
cannot be used on my system, since it does not suppress valgrind's crash
when it tries to run inkscape with GC enabled.
Here is the damage seen on a normal exit for a minimal run:
==16527== LEAK SUMMARY:
==16527== definitely lost: 567,697 bytes in 17,670 blocks
==16527== indirectly lost: 2,167,402 bytes in 73,234 blocks
==16527== possibly lost: 21,940,610 bytes in 282,461 blocks
==16527== still reachable: 21,470,100 bytes in 360,304 blocks
What can be done so that Inkscape makes a better effort at cleaning up
its enormous memory tangle when it exits while running in valgrind?
Some of the memory Inksape allocates is cleaned up, but it seems like a
very high percentage of memory allocations are tacked into this complex
memory structure, and inside valgrind the whole ball of yarn is just
dropped on the floor when the program reaches the final exit(), rather
than being unwound in an orderly fashion. (In theory GC may be
cleaning this up better, but I'm not sure how we can really know, since
valgrind cannot tell us.)
Could somebody who understands these parts of Inkscape PLEASE clean up
this mess, so that in future when "_INKSCAPE_GC==disable" Inkscape will
unwind its memory structures before exiting? At the very least we will
learn after this unwinding what memory is still left, and that will be
the result of existing bugs in the code. Once we obtain a baseline
inkscape that is usable once again in valgrind, we can reasonably expect
that by using valgrind developers will be able to catch the memory
problems they may introduce. Sadly that is far from true now, what with
so many thousands of lines of background noise in the log files to slog
through.
Admittedly some of the lines in valgrind's log file do come from
valgrind issues, but the ones I know about can be removed with:
cat >wcslen_sse2.supp <<EOD
{
wcslen1
Memcheck:Addr8
fun:__wcslen_sse2
fun:*
}
{
wcslen2
Memcheck:Cond
fun:__wcslen_sse2
fun:*
}
{
iffyinflate
Memcheck:Cond
fun:inflateReset2
fun:inflateInit2_
obj:*
}
EOD
valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15
--show-reachable=yes --suppressions=./wcslen_sse2.supp
--log-file=/tmp/vgfi.log src/inkscape
which improves the output to:
--16527-- used_suppression: 208319 wcslen1
--16527-- used_suppression: 142 wcslen2
--16527-- used_suppression: 330 iffyinflate
==16527==
==16527== ERROR SUMMARY: 97190 errors from 13437 contexts (suppressed:
208791 from 656)
I understand that there may be other problems in some libraries which
are called, but from the contents of the log file it looks like the
majority of the loose ends were directly created in Inkscape. (And we
can use valgrind suppression files, as above, to silence the unfixable
library problems.)
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years, 3 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
INKSCAPE
by Manuel Hiciano
it is possible to orient the inkspace for something specific drawing, I
mean add other features that allow you to work other aspects of technical
drawings.
Thank you!
Waiting for your answers ..
9 years, 5 months
Warnings check
by Johan Engelen
Hi all,
I'd like people to check what compiler errors are reported for trunk
on their system (Windows I can do myself), with these flags:
-Wall -Wformat -Werror=format-security -W -Wpointer-arith -Wcast-align
-Wsign-compare -Woverloaded-virtual -Werror=switch -Werror=return-type
-Werror -Wno-error=pointer-sign -Wno-error=unused-parameter
-Wno-error=unused-but-set-variable -Wno-error=strict-overflow
-Wno-error=write-strings
-Wno-error=format -Wno-error=format-extra-args
Please no comments about whether you like these flags or not, just what
build *errors* you get. (don't send me the warnings please!)
(On Windows, with these flags we are down to 3 errorring files, and I'm
working on them)
Thanks a lot,
Johan
9 years, 5 months
Windows build broken
by Johan Engelen
Hi all,
The Windows build is broken. Possibly after rev. 13225?
Error output:
compile src/ui/dialog/pixelartdialog.cpp
Make error line 304: problem compiling:
src/ui/dialog/pixelartdialog.cpp: In member function 'void
Inkscape::UI::Dialog::PixelArtDialogImpl::vectorize()':
src/ui/dialog/pixelartdialog.cpp:414:65: error: no matching function for
call to 'Glib::Thread::create(sigc::bound_mem_functor0<void,
Inkscape::UI::Dialog::PixelArtDialogImpl>)'
src/ui/dialog/pixelartdialog.cpp:414:65: note: candidates are:
c:\devlibs/include/glibmm-2.4/glibmm/thread.h:228:18: note: static
Glib::Thread*
Glib::Thread::create(const sigc::slot<void>&, bool)
c:\devlibs/include/glibmm-2.4/glibmm/thread.h:228:18: note: candidate
expects
2 arguments, 1 provided
c:\devlibs/include/glibmm-2.4/glibmm/thread.h:273:18: note: static
Glib::Thread*
Glib::Thread::create(const sigc::slot<void>&, long unsigned int, bool,
bool, Glib::ThreadPriority)
c:\devlibs/include/glibmm-2.4/glibmm/thread.h:273:18: note: candidate
expects
5 arguments, 1 provided
Thanks for the fix,
Johan
9 years, 6 months
Private implementations of widgets
by Alex Valavanis
Hello All,
Just wondering if we ever came up with a coding style for the private
components of our widgets and dialogs. Our GUI components, for
example, the dialog in [1] contain many different Gtk widgets (rather
than pointers/refs to widgets) and so we need to include lots of
<gtkmm/*.h> headers in our GUI class definitions.
If the embedded widgets were replaced by references to objects, we
could just use forward declarations of the appropriate classes and
then pull the header inclusions into the relevant .cpp files so it
should improve our compilation times.
Is there a reason why we don't do more of this already?
AV
[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/u...
9 years, 6 months
