August 2014 - Inkscape Devel - Inkscape Mailman

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

Create releases more regularly
by Sebastian Zartner 15 Feb '16

15 Feb '16

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

17 40

Re: [Inkscape-devel] Devlibs 46 too slow
by Mark Titchener 04 Feb '16

04 Feb '16

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. > >

3 3

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

Transformation center issues
by Diederik van Lierop 20 Feb '15

20 Feb '15

Hi people, 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 0.91 release. Diederik

4 5

C++11 for Experimental Branch?
by Tavmjong Bah 22 Nov '14

22 Nov '14

Hi, I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11? I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4). Tav

9 26

0.91 Bug Hunt Status
by Bryce Harrington 09 Oct '14

09 Oct '14

Development focus: 0.91.x series Pts Bug Age Date Assignee Description === === === ==== ======== =========== 6 1299948 0 05/11 Liam P. White LPEs with linked paths sometimes do not recalculate after undo 6 1310266 0 05/10 jazzynico Update the man page with '-i -j' for plain SVG export options 6 1315416 0 05/03 jazzynico [0.91 Tutorial Review] issues with "Basic" tutorial 6 1315453 0 05/05 Ryan Lerch [0.91 Tutorial Review] issues with "Shapes" tutorial 6 1315457 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with "Advanced" tutorial 6 1315480 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with " Bitmap tracing" tutorial 6 1315483 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with " Calligraphy" tutorial 6 1315485 0 05/05 Ryan Lerch [0.91 Tutorial Review] issues with "Elements of Design" tutorial 6 1315487 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with "tips and tricks" tutorial 6 1316591 0 05/06 Mohamed IKBEL Boulabiar copy-paste typo in the dbus document interface 6 1318289 0 05/11 Masato HASHIMOTO preferences > bitmap > rendering shows po file headers 6 1318345 0 05/11 Masato HASHIMOTO untranslatable strings in trunk-r13348 12 1318532 0 05/12 Masato HASHIMOTO Extension/Guides creator: Render fails 3 1247448 0 05/10 bcrowell INKSCAPE_PORTABLE_PROFILE_DIR should be on man page 3 1317140 0 05/09 jazzynico Tutorials: supported generic font names in trunk have changed 3 1318328 0 05/11 Masato HASHIMOTO typo in trunk-r13348 3 1318671 0 05/12 Masato HASHIMOTO url for New in This Version is obsolete 3 1314910 0 05/01 Claus Johansen Font size specification Total Score: 99 / 1500 Scoring: -------- 12, 9, 6, 3 for importances critical, high, medium and low +1 point per year of the bug report's age x2 if bug is tagged 'regression' x2 if closed the week it was declared Bug of the Week Bug of the Week --------------- Ryan Lerch closed 30 points worth of bugs, due to hammering our tutorials into shape. Ryan, would you please find us a good Bug of the Week for May 12-18? Bryce

11 47

Changing trunk to 96 pixels per inch.
by Tavmjong Bah 22 Sep '14

22 Sep '14

Hi, The experimental branch has been using 96 pixels per inch per the CSS 2.1 standard for over two months now without complaint. Is there any objection to switching trunk to this value? As Inkscape has switched to using 'pt' for text size by default, it is important that this change happen to ensure that the size of text rendered in browsers match the size of text rendered in Inkscape. Tav

8 22

Gtk+ 3 build bit-rot alert!
by Alex Valavanis 05 Sep '14

05 Sep '14

Hello All, I thought I'd quickly check how we're doing with the Gtk+ 3 build in Ubuntu Utopic, and was unpleasantly surprised to see that: (a) A tonne more symbols that have been deprecated in Gtk+ 3.10 (principally, GtkAction) (b) We have a few regressions, and have resumed use of some deprecated symbols that we had previously replaced. (e.g., GtkHBox) I have updated bug #1016020 with the latest build log (20k lines caused by deprecation warnings!!) and summarised the failures in the description. Obviously, (a) isn't our fault, but we should try to regain the progress we had made! (b) is more of a concern, since we're actually moving backwards! Ultimately, we should really try to enforce "-Werror=deprecated-declarations" in our dev builds, but clearly we're far away from that goal. Would it be reasonable to target a deprecation-free build for Inkscape 1.0? In the meantime, can I please request that from now on, everyone runs a strict build with both Gtk+ 2 and Gtk+ 3 before merging in any new features, so that we can ensure that we're not introducing any new warnings? Thanks, AV [1] https://bugs.launchpad.net/inkscape/+bug/1016020

7 13