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
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
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
6.72 57.32 4.44 563 0.01 0.01
5.51 60.96 3.64 1216 0.00 0.00
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
std::allocator<Geom::Path> > const&, Geom::Affine const&)
0.06 65.30 0.04 8 0.01 0.01
0.05 65.33 0.03 885444 0.00 0.00
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
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?
I initially asked at
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
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.
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
> > used to reproduced the bug were all using an Intel GPU. Tests with an
> > 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-18.104.22.168z),
> 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.
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.
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?
- 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.
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
The Inkscape community proudly announces the release of Inkscape 0.91.
Inkscape is a drawing and painting tool similar to Illustrator,
CorelDraw, and Xara X, but with features, new tools, and interface style
of its own. It emphasizes the W3C standard Scalable Vector Graphics
(SVG) file format, but reads and writes a wealth of other formats
including PDF, so it is an easy complement to your other graphics and
desktop tools. Best of all, Inkscape is created *by* the community *for*
the community: Inkscape is 100% Open Source and freely available to
everyone in the world.
This release marks the culmination of a multi-year effort to switch to a
new internal graphics rendering engine, Cairo. This brings performance
enhancements and more accurate rendering of drawings. Thanks go
especially to Google for sponsoring much of this work.
A new Trace Pixel Art feature enables creation of vector art from
bitmaps, sprites, and icons. A new Symbols Library provides reusable
graphics elements - you can even read in Visio symbol libraries. New
Snapping options and improved Snap preferences make it easier to quickly
place items in the alignments you need. The tools for arranging objects
offer several new ways to position the elements of a drawing. Tons of
other little improvements have been made across all the other tools as
Several new file formats are supported, including FXG, SIF and HTML5
export; and VSD and CDR import. EMF/WMF are now readable and writable
for all platforms. And XCF, PDF, EPS, and PS+LaTeX support are improved.
Inkscape has a rich Extension ecosystem, which is well known for
bringing clever, cool, and innovative new ideas. Over a dozen new
extensions are added in this release, including an Isometric Grid
Generator, a Bitmap Cropper, a Text Extractor and a Text Merger, an HSL
Adjuster, a Font Replacer, a Voronoï Diagram Creator, and more.
The above barely scratches the surface of all the new stuff included in
this release. For the full story, including examples and screenshots,
please see our detailed Release Notes:
The Inkscape developers plan to meet for a 3-day Hackfest in Toronto at
the end of April 2015. You can help us to improve Inkscape by donating
to help cover travel, room and board so our international volunteer
developers can attend the hackfest in person:
Our screenshots page is used to show off the latest cool features.
Currently it's showcasing 0.48 features. Can you help provide
screenshots (and/or descriptive text) for some of the visually
stimulating capabilities that 0.91 brings?
As a reminder, here's our comprehensive list of new features this release:
Please feel free to update the screenshots page directly, if you have a
website editing account. Otherwise, reply to this thread with your
contribution and one of us on the web team will help get it landed!
Finally we are here. The official Inkscape 0.91.0 tarball now exists
and can be downloaded here:
Packagers please do your thing, and reply here when you've uploaded
Everyone else, join me this evening in updating website links, news
items, documentation, and so on. We'll need to also put final touches
on release announcements and complete translation work.
Once we have Linux, OSX and Windows packages present and accounted for,
we can pull the trigger on sending out release announcements.
I'm sorry for the potential confusion in my email:
I meant to say, please sign up for inkscape-tester@...233...
You can also register yourself for jenkins.inkscape.org, but that is only needed when you want to help maintain and improve the Jenkins setup.
----- Reply message -----
From: "Christoffer Holmstedt" <christoffer.holmstedt@...400...>
To: "Inkscape Devel List" <inkscape-devel(a)lists.sourceforge.net>, <inkscape-tester(a)lists.sourceforge.net>
Subject: [Inkscape-devel] Jenkins
Date: Sat, Jan 31, 2015 06:13
Thanks for the information about that tester mailing list, I've signed
up. I'm interested in testing and verification so this could perhaps
be a good way into the core of inkscape source code.
2015-01-30 23:44 GMT+01:00 Johan Engelen <jbc.engelen@...2592...>:
> Hi all,
> Our "continuous integration" system, Jenkins, is up and running. It
> does automated builds, checks for bugs, runs the unittests, generates
> documentation with doxygen and will publish it online, and in future
> will also run rendertests.
> Currently it does those things for Inkscape trunk and 0.91.x branches;
> and also runs some jobs for lib2geom trunk.
> If some job fails (i.e. build is broken, a test no longer passes, or
> clang scanbuild discovers a new potential bug), Jenkins will send a
> notification email to the inkscape-tester SF maillist. If you are an
> active developer, please sign up for that maillist if you have not already.
> You do not need to sign up, unless you want to help maintaining and
> improving the system. All help is welcome. If you want to help, sign up,
> and let us know so we can give you more rights. Currently, only I and
> Martin Owens have full access. That is definitely not enough, so let
> yourself be known if you are interested!
> Have a look here: http://jenkins.inkscape.org
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> Inkscape-devel mailing list
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
Inkscape-devel mailing list