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
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
C++11 for Experimental Branch?
by Tavmjong Bah
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me
wondering about using C++11 in the experimental branch as 'auto' is so
much nicer that "std::map<SPDocument*,int>::iterator iter". When can we
start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only
shows results for one Window's compiler. Is there a test program we can
run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC
since 4.4).
Tav
8 years, 10 months
0.91 Bug Hunt Status
by Bryce Harrington
Development focus: 0.91.x series
Pts Bug Age Date Assignee Description
=== === === ==== ======== ===========
6 1299948 0 05/11 Liam P. White LPEs with linked paths sometimes do not recalculate after undo
6 1310266 0 05/10 jazzynico Update the man page with '-i -j' for plain SVG export options
6 1315416 0 05/03 jazzynico [0.91 Tutorial Review] issues with "Basic" tutorial
6 1315453 0 05/05 Ryan Lerch [0.91 Tutorial Review] issues with "Shapes" tutorial
6 1315457 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with "Advanced" tutorial
6 1315480 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with " Bitmap tracing" tutorial
6 1315483 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with " Calligraphy" tutorial
6 1315485 0 05/05 Ryan Lerch [0.91 Tutorial Review] issues with "Elements of Design" tutorial
6 1315487 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with "tips and tricks" tutorial
6 1316591 0 05/06 Mohamed IKBEL Boulabiar copy-paste typo in the dbus document interface
6 1318289 0 05/11 Masato HASHIMOTO preferences > bitmap > rendering shows po file headers
6 1318345 0 05/11 Masato HASHIMOTO untranslatable strings in trunk-r13348
12 1318532 0 05/12 Masato HASHIMOTO Extension/Guides creator: Render fails
3 1247448 0 05/10 bcrowell INKSCAPE_PORTABLE_PROFILE_DIR should be on man page
3 1317140 0 05/09 jazzynico Tutorials: supported generic font names in trunk have changed
3 1318328 0 05/11 Masato HASHIMOTO typo in trunk-r13348
3 1318671 0 05/12 Masato HASHIMOTO url for New in This Version is obsolete
3 1314910 0 05/01 Claus Johansen Font size specification
Total Score: 99 / 1500
Scoring:
--------
12, 9, 6, 3 for importances critical, high, medium and low
+1 point per year of the bug report's age
x2 if bug is tagged 'regression'
x2 if closed the week it was declared Bug of the Week
Bug of the Week
---------------
Ryan Lerch closed 30 points worth of bugs, due to hammering our
tutorials into shape. Ryan, would you please find us a good Bug of the
Week for May 12-18?
Bryce
8 years, 11 months
[GSOC Swatches] Latest code check in
by Tavmjong Bah
Hi Tomasz,
I just looked at your latest code check-in. You've added in style.h:
sigc::connection fill_ps_changed_connection;
sigc::connection stroke_ps_changed_connection;
to the already existing:
sigc::connection filter_modified_connection;
sigc::connection fill_ps_modified_connection;
sigc::connection stroke_ps_modified_connection;
How does "changed" differ from "modified"? This is a place where adding
a comment or two would really be helpful to some future developer in
understanding the code.
Any progress with hatches?
Tav
9 years, 1 month
Fix for #601336 (Pattern rotation crash)
by Liam White
Hi all,
I came up with a fix for this week's bug of the week (
https://bugs.launchpad.net/inkscape/+bug/601336 ). However, I'm bringing it
up here for two reasons:
1. It's a fairly large patch (and it modifies sp-item.h)
2. It introduces new, little-tested functionality
I'm more concerned about the second item on the list. The fix was to
introduce separate knots for stroke and fill patterns, and to make stroke
pattern transformations independent of fill transformations. If anyone has
time, I'd appreciate any feedback.
The diff is attached. If for some reason you can't download it, I've also
pastebinned it here: http://paste.debian.net/113020/
Thanks,
Liam
9 years, 1 month
Windows x64 and gtk3
by Liam White
Hi all,
I've added a gtk3 build rule to the 64-bit Windows devlibs[0].
I'd like people to start testing out the gtk3 look on Windows.
As the gtk3 for x86 developers probably figured out, the MS-Windows default
theme looks awful with the new gtk3 version[1]. So I've again decided to
stick with the Adwaita theme for compilation, which is much nicer[2].
I don't plan on returning to Windows anytime soon, so I would advise all
who build on Windows to please fix any problems I might have overlooked in
the build rule.
Thanks,
Liam
[0]. See this
<http://bazaar.launchpad.net/~inkscape.dev/inkscape-devlibs64/trunk/revisi...>
[1]. See https://db.tt/js7hR38Y
[2]. See https://db.tt/EGwiP0ft
9 years, 1 month
Inkscape Windows compile instructions and MinGW-w64/MSYS2
by Ruben Van Boxem
Hi everyone,
I wanted to explore the possibility of a 64-bit Windows build of Inkscape (for obvious reasons of increased memory availability), and discovered the "effort" had already been done by the great people of MSYS2 and MinGW-w64.
I would strongly suggest the Windows developers look into switching to this development platform instead of the current, manually maintained "devlibs" setup. Perhaps this suggestion can be made more plausible if I attempt to explain what MSYS2 and MinGW-w64 provide.
MinGW-w64 is an active project that provides Win32 headers and libraries so that GCC can be used on Windows, both 32- and 64-bit. It has replaced "ye olde" MinGW.org on numerous Linux distros (most notably Debian, Fedora, OpenSUSE, Ubuntu, and Arch). It is also the toolchain distributed alongside the Qt SDK releases.
MSYS2 is an updated version of the old MSYS (it takes a newer version of Cygwin, applies the MSYS patches, and presto: a Unix shell environment for building Unix/cross-platform software on Windows). Additionally, MSYS2 provides a complete repository of binary packages, linux-distro style. What the developers did was port Arch Linux' package manager, pacman, and create a whole ecosystem around it of ready-made MinGW-w64 packages. The full list can be found here.
You'll notice that the list contains a mingw-w64-inkscape package. What this means is that there is an easy way of obtaining/building/... inkscape on Windows, without the need to jump through too many hoops.
I'm not saying you guys should drop everything and come hide in the shade of MSYS2, but instead evaluate the current build process on Windows, and perhaps provide a simplified way of developing Inkscape on this platform. A free bonus would be the possibility of providing a 64-bit Inkscape build, which is already possible without any 64-bit Windows patches thanks to good code by you guys ;-).
Also note that cross-compilation from Linux shouldn't be much harder either, all the aforementioned distros have an extensive list of MinGW-w64 libraries at their disposal, and using CMake should make it all "just work". The current wiki's instructions look abysmally complicated compared to the simplicity made possible by the MinGW-w64/MSYS2 combo.
I strongly hope you take this into consideration, as it will lead to a lower entry for developing Inkscape on windows, which in turn will lead to quicker bug-fixing (I hope ;-)).
Thanks and keep up the fine work!
Ruben (known as rubenvb in the MinGW-w64 mailing community)
9 years, 1 month
