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, 8 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, 3 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, 3 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, 3 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, 5 months
Hackfest C++11 migration discussion
by Alex Valavanis
Summary: We are considering adopting new cleaner & more flexible C++
language features. This may not work with some older compiler
versions. Opinions are warmly welcomed!
-----
Hi All,
At the Hackfest, we discussed adopting features from the C++11
standard into our code. The advantages are (among others)
significantly cleaner, more flexible and more readable syntax. I've
included three examples at the end of this message.
Our discussion included consideration of users of older compilers. A
convenient summary of compiler support is available at [1]. Several
features (illustrated in the examples below) are well supported,
including range-based for loops, type inference and variadic
templates.
If we adopt these three specific features, we will require:
GCC >= 4.6
Clang >= 3.1
(or another suitable compiler!)
A complete migration to C++11 would require:
GCC >= 4.8.1
Clang >= 3.3
I propose that we adopt C++11 on a feature-by-feature basis, with
discussion before requiring any bump in compiler version. We can
track this in the wiki or similar.
We could potentially consider introducing a couple of the "safer"
features within the next release cycle. Maybe even in time for 0.92?!
I will be pushing some demos of C++11 features to the branch
lp:inkscape/~valavanisalex/inkscape/cpp11-port [2] for testing by
other devs/testers before we consider merging anything into trunk. I
will let you know when anything interesting is there!
We're very interested in any opinions or comments! Will this
migration affect you? Is it good for the project? Do you see any
trouble ahead?
Best wishes,
Alex
[1] http://en.cppreference.com/w/cpp/compiler_support
[2] https://code.launchpad.net/~valavanisalex/inkscape/cpp11-port
(Examples follow)
== 1. Type inference ==
The compiler can automatically determine the type of variables, based
on the return type of functions etc. For example:
std::vector<std::pair<Glib::ustring, Glib::ustring> > pairs =
ColorProfile::getProfileFilesWithNames();
becomes...
auto pairs = ColorProfile::getProfileFilesWithNames();
== 2. Range-based for-loops ==
Often, we just want to iterate over the entire contents of a
container. The syntax is much cleaner in C++11:
for(std::vector<Inkscape::SnapCandidatePoint>::iterator i =
_all_snap_sources_sorted.begin();
i != _all_snap_sources_sorted.end(); ++i){
// whatever
}
becomes...
for(auto &i : _all_snap_sources_sorted){
// whatever
}
== 3. Variadic templates ==
Sometimes we want many variants on the same function that take a
different number of arguments. For example:
template <typename CurveType, typename A>
void appendNew(A a) {
// whatever
}
template <typename CurveType, typename A, typename B>
void appendNew(A a, B b) {
// whatever
}
<snip />
template <typename CurveType, typename A, typename B,
typename C, typename D, typename E,
typename F, typename G, typename H,
typename I>
void appendNew(A a, B b, C c, D d, E e, F f, G g, H h, I i) {
// whatever
}
This long (and incomplete) set of functions can be replaced by a
single variadic template in C++11:
template <typename CurveType, typename... Args>
void appendNew(Args... args) {
// whatever
}
7 years, 9 months
Re: [Inkscape-devel] [Inkscape-user] Regarding Inkscape in Indian languages
by chandrakant dhutadmal
Hi Axel, David and others,
There is no issue or problem as far as translations are concerned. We already have the translations done for all Indic languages and these are also attached in the Bugs (https://bugs.launchpad.net/~cpdhutadmal ).
If this can be taken ahead, Indic language users will be very happy.
Regards,Chandrakant Dhutadmal.Pune, India.
On Friday, February 13, 2015 9:33 AM, Alex Mandel <tech_dev@...3215...> wrote:
On 02/11/2015 10:44 PM, chandrakant dhutadmal wrote:
> Hi All.
> We have submitted requests for bringing out localized Inkscape for Indian languages through various bugs filed. List of all such bugs filed can be looked at https://bugs.launchpad.net/~cpdhutadmal.
> We have also submitted translations for those languages. Would like to know from the community if we have considered making builds for Indic languages. If so, when are we going to do it. If not, can we have a discussions surrounding the topic ?
>
> RegardsChandrakant DhutadmalPune, India.
>
>
I suspect what is missing is volunteers to do the translation. How to
contribute a translation is outlined on this web page
https://inkscape.org/en/contribute/translations/
Thanks,
Alex
7 years, 10 months
Boolops progress
by Krzysztof Kosiński
There is a new toy "boolops-new" in 2Geom's source repository - it
computes an union of two paths using my new boolops code based on the
Greiner-Hormann algorithm.
What works:
- Union
- Intersection
- Adding difference and XOR is trivial
- Linear and Bezier segments of arbitrary degree
- Code is fairly clean and understandable
- Reasonably good performance, even though there are very few optimizations
What remains to be done:
- Could be simplified a bit and better documented.
- Intersection procedures for arc-arc and arc-Bezier cases. Currently
they throw UnimplementedError.
- Handling of degeneracies and second-order intersections. I have this
mostly planned out, except for a few nasty cases with overlapping
Bezier segments.
- Add &, |, / operators to PathVector. I think / will be better than
minus for set subtraction.
- Function that converts a nonzero winding pathvector to even-odd
winding pathvector with the same filled areas. It's a lot easier to do
this conversion than it is to do Booleans on nonzero winding fills.
I observed no crashes or hangs, though when two pathvectors overlap
exactly, some paths can be skipped in the output.
Since this code is already a lot better than the old attempts present
in 2Geom (path-intersection.h, shape.h, region.h and the like), I'm
going to remove them to reduce cruft.
Regards, Krzysztof
7 years, 11 months
Inkscape Devlibs (windows)
by Josh Andler
Hey all,
Now that Cairo 1.14.2 is out, can both the 32-bit and 64-bit devlibs
get updated? I think we should aim to get 0.91.1 out in maybe a month
or so. I will start looking into doing backports later this week. I
figured I'd bring up the devlibs first though since they seem to take
a bit to get updated.
Cheers,
Josh
8 years
RFC: Switch to Google Test framework
by Bryce Harrington
Hi all,
At the hackfest today we discussed the Boost test suite vs. the Google
test suite. Both options are very good and better than cxxtest that we
use currently, and should be straightforward to move to.
We tentatively decided on Google test. 2geom uses it, so many of us
already have familiarity with it, and it will keep the two projects
consistent. Boost's commands have prefixes which makes for a bit more
typing, whereas Google test's are more brief. KK liked Google test's
handling of templates better too.
Does anyone have a strong differing option?
We're hoping to have the decision finalized by the end of the week.
Bryce
8 years
