July 2015 - Inkscape Devel - Inkscape Mailman

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

7
20
0 / 0

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

17
40
0 / 0

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

4
5
0 / 0

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

3
3
0 / 0

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

8
21
0 / 0

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

3
8
0 / 0

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 }

8 years, 1 month

10
19
0 / 0

Switch

by Jabiertxo Arraiza Cenoz

Hi to all. Im thinking going to work on "switch" code now "full" implemented in Inkscape but without GUI. Tav give me help on it. I have a idea on how to get working but have questions. Im focused on languaje selector but maybe im wrong, maybe need a full "switch" GUI with "requiredFeatures", "requiredExtensions" and "systemLanguage" conditional processing attributes. Realy Im not sure if "requiredFeatures" and "requiredExtensions" are useful to handle on Inkscape or maybe is better for use on the XML editor or raw SVG editing for the moment. In my mind, with language only point of view, I need a object dialog method to redraw a "switch", and a language -or "switch"- widget to: * Add multilenguage title and desc * Switch all "switches" to one lang * Add lang to a "switch". Global? * Remove a lang * Insert selected element to a new "switch" in the default lang. * Handle more Aria atributes? By the way, about "switches" in webpages with "systemLanguage" conditional processing attribute, whats the best way to user based switch a lang? We need a JS hack? Now im very bussy whith my payed work but hope can take some time to this proyect but sure not as dedicated as previously :( Regards, Jabier.

8 years, 1 month

4
10
0 / 0

Error compiling for Win64

by Christian Budde

Hello, today I wanted to build the latest trunk version for Win64, but I encountered an issue I don't know how to fix myself. What I did so far is to follow the instructions here: http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows_64-bit I also tried with more recent versions of MinGW-w64 now that Sourceforge is back online. Below is the error reported. It seems to be related to MinGW-w64, but I'm not sure what code actually triggered this and how to solve it. compile src/graphlayout.cpp Make error line 311: problem compiling: In file included from src/style.h:21:0, from src/graphlayout.cpp:34: src/style-internal.h:522:107: warning: unused parameter 'inherits' [-Wunused-parameter] SPIEnumBits( Glib::ustring const &name, SPStyleEnum const *enums, unsigned value = 0, bool inherits = true ) : ^ src/style-internal.h:522:107: warning: unused parameter 'inherits' [-Wunused-parameter] In file included from C:/mingw64/x86_64-w64-mingw32/include/c++/bits/move.h:57:0, from C:/mingw64/x86_64-w64-mingw32/include/c++/bits/stl_pair.h:59, from C:/mingw64/x86_64-w64-mingw32/include/c++/bits/stl_algobase.h:64, from C:/mingw64/x86_64-w64-mingw32/include/c++/bits/char_traits.h:39, from C:/mingw64/x86_64-w64-mingw32/include/c++/ios:40, from C:/mingw64/x86_64-w64-mingw32/include/c++/ostream:38, from C:/mingw64/x86_64-w64-mingw32/include/c++/iostream:39, from src/graphlayout.cpp:15: C:/mingw64/x86_64-w64-mingw32/include/c++/type_traits: In instantiation of 'struct std::remove_reference<SPItem*&>': C:/mingw64/x86_64-w64-mingw32/include/c++/bits/move.h:87:5: required by substitution of 'template<class _Tp> constexpr _Tp&& s td::forward(typename std::remove_reference<_From>::type&&) [with _Tp = SPItem*&]' C:/mingw64/x86_64-w64-mingw32/include/c++/bits/stl_construct.h:75:68: required from 'void std::_Construct(_T1*, _Args&& ...) [ with _T1 = SPItem*; _Args = SPItem*&]' C:/mingw64/x86_64-w64-mingw32/include/c++/bits/stl_uninitialized.h:75:53: required from 'static _ForwardIterator std::__uninit ialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = SPItem* *; _ForwardIterator = SPItem**; bool _TrivialValueTypes = false]' C:/mingw64/x86_64-w64-mingw32/include/c++/bits/stl_uninitialized.h:125:41: required from '_ForwardIterator std::uninitialized_ copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = SPItem**; _ForwardIterator = SPItem**]' C:/mingw64/x86_64-w64-mingw32/include/c++/bits/stl_uninitialized.h:278:63: required from '_ForwardIterator std::__uninitialize d_copy_a(_InputIterator, _InputIterator, _ForwardIterator, std::allocator<_Tp>&) [with _InputIterator = SPItem**; _ForwardIterat or = SPItem**; _Tp = SPItem*]' C:/mingw64/x86_64-w64-mingw32/include/c++/bits/vector.tcc:213:29: required from 'std::vector<_Tp, _Alloc>& std::vector<_Tp, _A lloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = SPItem*; _Alloc = std::allocator<SPItem*>]' src/snap.h:148:100: required from here C:/mingw64/x86_64-w64-mingw32/include/c++/type_traits:1476:5: internal compiler error: in finish_member_declaration, at cp/seman tics.c:2828 { typedef _Tp type; }; ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://sourceforge.net/projects/mingw-w64> for instructions. Can anyone point me in the right direction here? Kind regards, Christian Budde -- Christian-W. Budde Eleonorenstr. 17 30449 Hannover Tel.: +49 511 31048857 E-Mail: Christian@...3256... WWW: http://www.savioursofsoul.de/Christian

8 years, 1 month

2
1
0 / 0

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

8 years, 1 month

3
3
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Inkscape Devel July 2015