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, 5 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, 1 month
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.
7 years, 10 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-
8 years, 10 months
Why is the position of this line of code so touchy?
by mathog
In the files in src/display there are many instances of this
Inkscape::DrawingContext::Save save(dc);
First thing, I don't understand the syntax. What does the lower case
"save" in that line indicate? The only places "::Save save(" appear in
the source code are instances
of this line.
Secondly, it acts strangely. Moving it around breaks graphics for some
reason that
escapes me. For instance this:
Inkscape::DrawingContext::Save save(dc); //PROBLEM LINE
dc.transform(aff);
double thickness = decorateItem(dc, aff, phase_length);
dc.setLineWidth(thickness);
dc.strokePreserve();
dc.newPath();
results in mangled graphics (text decoration drawn as if with a very
thick line, but in what appears to be the correct location), whereas
moving the first two lines above into
double DrawingText::decorateItem(DrawingContext &dc, Geom::Affine
const &aff,
double phase_length)
as the first two lines of that method results in normal graphics (text
decoration drawn with the expected line thickness). That is:
line1
line2
call
is broken but
call
(inside called function)
line1
line2
works. Moving "dc.setlinewidth()" from the position shown above into
decorateItem() as the line before its return does not make any
difference in either of these cases. decorateItem() just defines a
cairo path with moveto/lineto on
_ct in dc, it doesn't touch anything else in the dc.
Using the debugger and stepping through showed that execution of the
problem line passes through this:
DrawingContext::Save::Save(DrawingContext &dc)
: _dc(&dc)
{
_dc->save();
}
in drawing-context.cpp. _dc->save() just does
cairo_save(_ct);
I have never seen anything quite like this when using cairo directly,
that is, calling cairo_save() and cairo_restore() has never resulted in
mysteriousness of this level. And that seems to be mostly what the
DrawingContext does - it keeps track of (private)
cairo_t *_ct;
I would have thought that passing dc by reference should have made the
position of the problem line before the call, or just within the called
function, a moot point, but apparently not. This is so even though when
the address of _ct was checked with dc.raw(), before and after the
problem line, it didn't change. Whether or not the problem line was
before or inside decorateItem().
Can somebody please explain what is happening here?
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years
Href sub-document model
by Martin Owens
Hey developers,
This is the model I'm going to implement for documents to reference
other documents:
SPDocument {
GSList *child_documents;
SPDocument *parent_document;
// Parent of parents until parent == NULL;
SPDocument *getRootDocument();
}
Then in uri-reference, check paths of existing child_documents, load the
referenced document and add to child_documents. Set parent_document.
That should keep things consistant.
The idea here is that we'll use this to track documents referenced in
<use tags> as well as <image tags> and attributes like 'marker-*:
url(...);' but not for non-vector graphics used in the image tag.
Thoughts? Advice?
Best Regards, Martin Owens
9 years
Image Data URIs
by Martin Owens
He devs,
I've been trying to read up on image tags special case, where a href
will start with data: and then proceed to have data. Since I want to
merge most of the sp-image logic into Inkscape::URI I need to know if
data uris are something the svg spec says should only be available to
image tags... or should be available to any href.
The svg 1.1 spec says nothing about data uris that I could find. Any
ideas?
In the end, I want hrefs to be able to be loaded, processed into
localised absolute references and even parsed for data if that's
generic. From the same Inkscape::URI object.
Does this seem sensible? I note the css url(...) handler isn't the same
as the href handler; so should something be done to help those converge
too?
Any thoughts would be appreciated.
Martin,
9 years
the Developer Education Book Campaign 2013 !
by Johan Engelen
Hello all,
In an effort to give back to our developers, I hereby present to you
the Developer Education Book Campaign 2013 !
We'd like to give an educational present to our most active
contributors. The board has decided to buy a programming book for each
of the top 10 contributors of 2013! The ranking is determined by the
number of commits to trunk in the past 12 months, as calculated by
Ohloh.net [1] [2]:
Kris de Gussem Alex Valavanis
Markus Engel Matthew Petroff
Nicolas Dufour Martin Owens
Tavmjong Bah Krzysztof Kosiński
Sebastian Wüst Alvin Penner
Thank you very much for your great work in 2013!!!
These 2013 rockstars can choose from one of the following books:
a) Effective C++, 3rd Ed.
by Scott Meyers
b) Refactoring: Improving the Design of Existing Code
by Martin Fowler
c) A Tour of C++ (C++11)
by Bjarne Stroustrup
The developer is also allowed to pass it on to the runner-up if he so
wishes. Because I initiated the book campaign, I will pass (don't worry,
I've already ordered my book ;).
So now you might think: wait a minute..., these coders get a book on how
to program... are they that bad? They are not bad; they could be even
better! We all can improve our coding, and there is no shame at all in
reading up and refreshing our coding skills. Every day I am reading
Stroustrup's C++11 tome in the train to work, no joke!
I hope you all will enjoy your present, and can perhaps share with us
the best things you've learned :-)
Cheers to a good start in 2014!
Johan
[1] http://www.ohloh.net/p/inkscape/contributors?query=&sort=commits_12_mo
[2] I'm sorry if you feel this metric is unfair and skewed. We had to
agree on some metric, knowing that any metric is imperfect.
9 years
Mac OS X Mountain Lion x86_64 packaging of 0.48.4
by Valerio Aimale
Hello,
I am not an official packager, but I was eager to have an updated
version of Inkscape for Mac OS X and I noticed that nobody is packaging
the new version.
I've packaged it for Mountain Lion and x86_64. It should be considered a
beta packaging. I've packaged from version 0.48+devel r12005
You can download it at:
https://rapidshare.com/files/3885726044/Inkscape_MountainLion_x86_64.dmg
The Mac Os X packaging infrastructure in the source tree is a bit
ancient. Things I've noticed:
- configure.ac uses syntax that is not conforming anymore with
autoconf/automake/authohear 1.13. Going forward that should be updated.
- the scripts osx-build.sh os-app.sh needs update for the newest Xcode
versions. they don't work out of the box.
- the dylib base relocation infrastructure needed to be rewritten
- the Platypus-derived ScriptExec executable might not be needed anymore
- in this version, the app bundle executes the sh script directly.
Features:
- The version I packaged runs gtk-2.0+quartz. It does not need
X11/Xquartz anymore to run. This is the direction GIMP has gone to as well.
- It uses the same theme as GIMP. I think it's a good consistency
decision, and it's the theme that looks best on Mtn Lion.
If somebody want to try and report problems, I'd appreciate it
Valerio
9 years, 1 month
