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
Developing on Mac
by Michael New
Hey Inkscape developers, I’ve spent the last several years both using Inkscape and working with C++, and I’d really like to contribute to the project now that I have some relevant skills. I develop on macs though, and I can’t seem to find any up-to-date instructions on building for mac. Can anyone point me to some current info?
Thanks for the help, and thanks for everything you guys do.
-Mike
7 years, 9 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
Transformation center issues
by Diederik van Lierop
Hi people,
The past weeks I've been trying to fix some transformation center offset
regressions, which were caused by the new unit/viewbox stuff. That should
all work reasonably well again, but it remains a headache. IMHO this
transformation center handling is broken by design, and judging by some
comments in the code I'm not the only one to think so. It requires all
kinds of special casing everywhere transformations are being applied, due
to the transformation center being expressed in horizontal/vertical
coordinates, relative to the center of the bounding box. Does anybody know
why it was designed like this?
If there are no strong objections, then I'd propose to use absolute
coordinates, and to apply transformations as if it were simply a point of a
path. This would make code much cleaner. We will no longer need to call
document->ensureUpToDate() to force an update of the bounding box everytime
the center is requested or changed. It might also allow us to get rid of
the weird behavior of the transformation center (which should rotate with
the item in case an object is rotated!)
Not that I'm going to change this now, but I might get to this after the
0.91 release.
Diederik
8 years, 7 months
"Flatten" vectors
by Alexander Brock
Hi,
When drawing stuff I usually have a lot of overlapping areas.
Sometimes I use a vinyl cutter to cut adhesive foil. Then I need
to select the topmost object and subtract it from every object
which is (partially) covered by the topmost object.
Next, I need to repeat the process with the second-to-topmost
object etc.
I also need to convert all strokes etc. to paths to actually get paths
plotted
with non-zero width, otherwise it's just one cut along the path which is
useless.
I also need to intersect all objects with their respective clip or mask,
if they are clipped or masked. For complex drawings this process takes a
lot of time.
I wondered if there's a plugin or something for "flattening" an image
like that,
essentially converting it to a set of non-overlapping closed paths
without stroke.
If there isn't such a functionality I'd like to program it.
In which way should this be done?
On which branch should I base this?
Are there any major changes to parts of Inkscape planned which would
interfere with this functionality / should I wait for some changes to be
finished before I start?
@Krzysztof Did you finish your API changes etc. you started in your GSoC
project?
Regards
Alexander
8 years, 7 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
Feature Freeze for 0.91
by Bryce Harrington
3. Frost. √ Experimental Branch is forked
√ Mainline Branch focuses on stabilization
√ Only production-ready code committed to Mainline
√ Post inkscape-0.91-pre0.tar.gz
√ Finalize any major changes to platform packaging
√ Release Notes should be >90% filled in.
√ Inkscape must pass >90% of 'make distcheck'
√ Start an About Screen contest
√ General Bug Hunt: 1500 points
√ Post additional inkscape-0.91-pre*.tar.gz releases
√ Packagers test creating pkgs of the -pre* releases
4. Feature Freeze √ Stable Branch is forked from Mainline
Regular development resumes on Mainline.
Avoid major refactorings on Mainline.
Only bug fixes committed to Stable Branch.
Bug fixes are cherrypicked from Mainline.
Inkscape must pass 'make distcheck'
String Freeze No further string changes allowed on Stable Branch.
Finalize tutorials to be shipped with release
Finalize other docs included in the release
Finalize about screen
Finalize Release Notes except Known Issues
Translators work on translations.
Recruit Release Wardens for Hard Freeze
Inkscape has completed the Frost phase and is moving into Freeze.
Translators, please fire up your engines! You have (at least) until
Nov 18th to commit translation updates to the stable branch.
------------------------------------------------------------------------
A stable branch lp:inkscape/0.91.x has been split off of trunk. Only
strict bug fixes and translations may be committed to this branch; for
anything else please seek release manager approval (Josh or Bryce).
# Stable branch
bzr clone lp:inkscape/0.91.x inkscape-0.91-stable
You will need to check this out only if you intend to check in fixes to
the stable branch.
IMPORTANT: Do not make changes to translatable strings in the stable
branch. If it is critical that a string change be made, please get
approval from the release managers first!
------------------------------------------------------------------------
The lp:inkscape branch (trunk) is now open for regular development
towards the 0.92.x series.
# Development branch
bzr clone lp:inkscape
You don't need to do anything with your current branch if you just want
to keep committing to the development branch.
Congrats to everyone that helped us get this far,
Bryce
8 years, 10 months
Merge of experimental branch
by Liam White
With Bryce's permission, I have merged the experimental branch into trunk.
Trunk is now open for development. Please do not make further commits
to experimental.
If you do not use a separate directory for build and source:
> $ bzr pull lp:inkscape
…
> Conflict: can't delete src/dialogs because it is not empty. Not deleting.
> 1 conflicts encountered.
> Now on revision 13641.
> $ rm -rf src/dialogs
> $ bzr revert
This should fix your local copy.
8 years, 10 months
