November 2013 - Inkscape Devel

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

performance problems and possible remedies?
by Yale Zhang 29 Sep '16

29 Sep '16

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

7 20

non-Unicode symbol fonts do not work on Windows. Bug 165665. Do we need the flag USE_PANGO_WIN32 ?
by Alvin Penner 09 May '15

09 May '15

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.-Bug-… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

7 16

Improved gears extension
by Jürgen Weigert 06 May '14

06 May '14

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-

2 1

Mac OS X Mountain Lion x86_64 packaging of 0.48.4
by Valerio Aimale 10 Feb '14

10 Feb '14

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

10 27

Devlibs 46 too slow
by LucaDC 19 Dec '13

19 Dec '13

After updating to devlibs r46 moving objects around becomes too slow in my system and Inkscape is nearly unusable even for simple drawings. Open a new document, draw a rectangle and move it around: the lag is huge. Even changings of the cursor when hovering over it are updated with delays of 1 s or more. Moving and snapping guides (not to guides), on the other hand, is very fast. My system is a Pentium 4, 3,2 GHz, 2 Gb RAM with Windows XP SP3. Reverting to devlibs r45 (trunk 12277) gives back the previous (acceptable) response time. I know my system is old, but with r45 it's fine for all my needs. Isn't this terrible performance drop avoidable? Inkscape is already not a jaguar... Regards. Luca -- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

5 22

Fwd: Re: [scribus-dev] C++11
by Johan Engelen 16 Dec '13

16 Dec '13

Hi all, I asked the Scribus guys what their plans are regarding C++11. They had not thought about it much, but I got a very interesting reply, that is relevant for us too. Please read below. regards, Johan -------- Original Message -------- From: - Thu Nov 07 23:35:19 2013 Date: Thu, 07 Nov 2013 02:21:04 +0100 From: Jean Ghali <jghali@...373...> To: Scribus Development Mailing List <scribus-dev@...3050...>, jbc.engelen@...2592... Subject: Re: [scribus-dev] C++11 Hi, For making the switch to C++11, all C++ dependencies have to be compiled using C++11 too. It is indeed dangerous to link C++11 objects and C++ objects compiled according to previous standards: - http://gcc.gnu.org/wiki/Cxx11AbiCompatibility - http://stackoverflow.com/questions/9408656/do-we-need-to-recompile-librarie… - http://stackoverflow.com/questions/10065055/why-is-stdlist-bigger-on-c11 So basically the main requirements for us to switch to C++11 would be that qt binaries provided by distros are compiled according to C++11. I don't known if this is the case currently but i doubt it. Cheers, Jean Ghali Le 06/11/2013 20:05, Johan Engelen a écrit : > Hi all, > I'm rooting for requiring C++11 for lib2geom ASAP. How badly would this hurt Scribus > development? ;) > Are there any plans about when to make the switch to C++11 for Scribus? > > (I'm not subscribed to the list, so please also send replies directly to my address) > > Cheers, > Johan > (Inkscape and 2geom developer)

2 3

Re: [Inkscape-devel] Inkscape and SMIL support
by Susan Spencer 04 Dec '13

04 Dec '13

As mentioned previously in this thread, details of fundraising are typically discussed *after* a proper estimate is developed. If this is a serious discussion (which I believe it is) then the following actions are up next: 1. Identify the programmers, testers, documenters and users who will participate. (Participants can assume multiple roles) 2. The programmers collaborate to create & share the requirements and constraints 3. The testers specify & share the testing and signoff requirements, based on output of #2 4. All participants specify documentation requirements to meet needs of both the users and the future developers/maintainers 5. Estimate the cost & delivery schedule 6. Design the fundraising campaign (which is another separate effort) if you're going to raise funds from the public then you can't be code cowboys about this, no matter if you believe this is a relatively small effort. Performing the above steps and publishing the results helps build momentum for public monetary support and creates tremendous public confidence. it also gives the tech media something to report regularly building up to the fundraising start date. Use the machine wisely, publicity never hurts! Assuming that remote collaboration results require more time than face-to-face sprints, we can shoot for 30 to 60 days for #1-5, 30 days maximum for #6, so max 90 days till fundraising. My skills aren't in programming, but if you would like me to I can help with project development & fundraising. If there are others more connected to Inkscape than I who would like to step up for this work, please do! - Susan >

8 25

Inkscape 0.48.5
by Alex Valavanis 03 Dec '13

03 Dec '13

Hi All, Do we have a schedule for the next stable point release? Builds are now failing on Ubuntu Saucy using 0.48.4 because of bug #1095364 <FTBFS with gcc 4.8> [1]. Cheers, AV [1] https://bugs.launchpad.net/inkscape/+bug/1095364

7 27

Removing ID attribute from group (XML editor) causes crash
by Bryan Hoyt | Brush Technology 03 Dec '13

03 Dec '13

While editing an Inkscape-created document, if I delete the ID attribute of a group (or any other element, on further investigation) using the XML editor, and then select that element in the visual editor, Inkscape crashes. The ID in question is not referenced elsewhere in the document. Is it valid SVG to have objects without IDs? It certainly seems like it should be, particularly for hand-crafted SVG. I can reproduce this trivially in Inkscape's trunk build from 22 Sep 2013 on a blank document with nothing but a plain rectangle. - Bryan -- Bryan Hoyt, *Software Developer* -- Brush Technology *Ph:* +64 3 741 1204 *Mobile:* +64 21 238 7955 *Web:* brush.co.nz

4 10