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
Impressions on Inkscape after extended usage
by Michael Grosberg
Hello,
In the past several months - closer to a year, actually - I've used Inkscape
in a tight production environment almost daily. I have produced hundreds
of illustrations for a computer-based technical course. During that period
I used Inkscape 0.48.5 and lately switched to test builds and release
candidates of 0.91. All of this time I have kept a list of the problems I ran
into using Inkscape. Some are plain bugs, some are more complex problems for
which I have no idea for a solution. After testing the new version to see
whether some of these problems have gone away, I thought I might share this
document with you.
Before I go on, I just like to say that these are mostly minor points. I am
an avid user and promoter of Inkscape even though my workplace has provided
me with a legal copy of Adobe Illustrator, which I think is inferior in
ease of use. I think Inkscape on the whole is a brilliant piece of software
and I'm thankful for all your efforts. But some problem just kept popping up
again and again.
So without further ado, here's the document (it's a google doc):
http://bit.ly/1yLzn0y
Thank you for any comment or feedback you might have.
- Michael Grosberg
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
Jenkins administration
by Johan Engelen
Hi all,
Jenkins, our CI system, has been down for more than a month. It looks
like the disk has filled up, and we need to do clean up / the build
tasks should clean up after themselves better (I suspect it has to do
with storing the results of too many older builds instead of just the
current one plus a few recent builds).
We need an administrator for Jenkins. Currently, I think only me and
Bryce have access, which is not good enough.
Who is interested in maintaining the automatic build/testing system?
Of course, you can tailor the system to your own likes; there is much to
be improved and I think all are open to whatever crazy plans you may
have :-)
http://jenkins.inkscape.org/
regards,
Johan
7 years, 9 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
Board Meeting @ Friday Oct 2nd, 2015
by Bryce Harrington
Hi all,
We'll be holding an Inkscape Committee meeting this Friday the 2nd of
October, on #inkscape-devel, at 1900 UTC (Noon PDT / 9pm CEST)
http://wiki.inkscape.org/wiki/index.php/Board_Meetings
All in the Inkscape community are welcome to attend.
Our agenda is open for any new business.
Thanks,
Bryce
----- Forwarded message from Tavmjong Bah <tavmjong@...8...> -----
Date: Mon, 28 Sep 2015 17:28:13 +0200
From: Tavmjong Bah <tavmjong@...8...>
To: Bryce Harrington <bryce@...961...>, inkscape-board(a)lists.sourceforge.net
Subject: Re: [Inkscape-board] Proposal for board meeting
An IRC meeting is an excellent idea.
Any day at noon PDT (9 PM CEST) is OK with me. Thursdays I have an SVG
WG meeting at 1:30 PM PDT (10:30 CEST).
My agenda items would be:
C++11
Hackfest 2016
Paid development
Tav
On Sun, 2015-09-27 at 12:20 -0700, Bryce Harrington wrote:
> Hi guys,
>
> Now that our board is re-manned, I'm thinking it'd make sense to call
> a
> meeting on IRC. I don't have anything major to discuss myself, but
> I'll bet the rest of you have some good ideas to float.
>
> How does some time first week of October sound? Thursday Oct 1st?
> Or
> would the weekend be better? I seem to recall that before we met at
> noon pacific time; would such a time be impossible for anyone?
>
> http://wiki.inkscape.org/wiki/index.php/Board_Meetings
>
> As far as agenda goes, I don't have anything to suggest - this past
> year
> we've accomplished so much! I figure we can just play it by ear, and
> leave the agenda to "opens".
>
> Bryce
>
>
>
>
>
> ---------------------------------------------------------------------
> ---------
> _______________________________________________
> Inkscape-board mailing list
> Inkscape-board(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-board
----- End forwarded message -----
7 years, 10 months
2Gom sync - high potential for regressions after r14226
by Krzysztof Kosiński
Hello
I recently made a commit that finally synchronizes the 2Geom version
used in Inkscape and the "upstream" version in 2Geom's Launchpad
repository. It compiles and appears to work correctly, but since there
were several potentially breaking changes in 2Geom, it has a high
potential for regressions.
The most important changes in 2Geom are:
1. The sign convention for cross(Point, Point) was flipped to match
the one for cross(D2<SBasis>, D2<SBasis>): it is a[X]*b[Y] -
a[Y]*b[X], not the other way around. I think I converted all uses, but
one can never know.
2. All nearestPoint() methods were renamed to nearestTime(), since
they return time (parameter) values, not points. nearestTime() for
Path and PathVector returns PathTime and PathVectorTime respectively.
PathTime encapsulates a curve index and a time value, while
PathVectorTime encapsulated a path index, a curve index and a time
value. The reason for using these types instead of extending the range
of the time parameter from [0, 1] to [0, N] is twofold:
- Packing these two parameters into the double type causes a loss of
acuracy as the indices increase. For example, referencing a point that
lies on the 32nd curve causes a loss of at least 5 bits of precision.
- For PathVector, there is an unnecessary O(N) step involved in
mapping the [0, N] time value to path and curve indices.
In the future, there will be two additional families of methods:
nearestPoint(), which will actually return the nearest point (I
avoided adding until the sync is done to simplify porting to the new
API), and nearestPosition(), which will compute both the nearest point
and the time value. Doing the latter can often save a lot of
calculations, since in many cases the point is computed from the time
or vice versa.
3. SVGEllipticalArc was renamed to EllipticalArc, and the old
EllipticalArc was removed. The only difference between them was that
EllipticalArc would throw exceptions if the constructor parameters did
not specify a valid arc, whereas SVGEllipticalArc just falls back to a
straight line. Additionally, a number of other improvements were made,
for example EllipticalArc no longer allocates a copy of itself when
transforming it.
4. There was a major cleanup of Path:
- Iterating between begin() and end_closed() will skip the linear
closing segment if and only if its endpoints coincide exactly.
SVGPathParser was modified to retain the old behavior of considering
the closing segment degenerate if it is shorter than some specified
tolerance.
- Internally, the path is now stored as a copy-on-write
boost::ptr_vector of Curve. This should give a performance boost,
since we are no longer using boost::shared_ptr-based copy-on-write for
each curve, but only for entire Paths.
- PathVector is now a real class, not a typedef of PathVector, This
allows several things to be implemented as methods instead of as
standalone functions.
- PathSink was improved. Instead of creating a switch-like structure
for the result of dynamic_cast of the abstract curve type to more
concrete types, please derive from PathSink.
- There is a new class called CairoPathSink for outputting 2Geom paths
and shapes to Cairo.
5. Circle and Ellipse were fleshed out, and contain many of the
methods found in Curve and Path.
6. There is a new intersection API, exposed as a method on shapes and
returning a class that contains two time values and the point of
intersection. There are methods for Line, Circle, Ellipse, Path and
PathVector.
Please test and report and regressions, but please make sure to check
whether they are really regressions - for example the eraser tool
sometimes doesn't work and it has nothing to do with the 2Geom sync,
but rather with some faulty code in livarot.
Regards, Krzysztof
7 years, 11 months
Another font issue: Calluna Regular
by C R
Calluna Regular, which is currently in use on the website is a commercial
font. While it's true that the regular version is offered under a free
license, it is not offered under an OFL license, and what's a bit worse, is
not licensed at all for use in documents, etc. (only desktop/web, and some
sites want to sell a web license for it, which is worrying).
So... heh.
Anyone want me to work on finding alternatives for that one too?
We pretty much need to.
-C
7 years, 11 months
