February 2014 - 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

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

Making inkscape usable in valgrind grumble
by mathog 03 Jun '14

03 Jun '14

Hi all, In order to find memory leaks, some types of access violations, and the use of uninitialized variables I depend on valgrind. The problem is that valgrind is barely usable with Inkscape. The output on even the most minimal session (open, type a few letters, format them, close) runs to just under 500K lines and takes 5 minutes to complete. Some of this may be because garbage collection must be turned off in order to use valgrind. That is: export _INKSCAPE_GC=disable; valgrind .... src/inkscape There is no choice in that though, because if it is not done valgrind crashes when it tries to run inkscape. (Ubuntu 12.10.4, 32 bit, current Trunk). There is a libgc.supp in the top of the distribution, but it cannot be used on my system, since it does not suppress valgrind's crash when it tries to run inkscape with GC enabled. Here is the damage seen on a normal exit for a minimal run: ==16527== LEAK SUMMARY: ==16527== definitely lost: 567,697 bytes in 17,670 blocks ==16527== indirectly lost: 2,167,402 bytes in 73,234 blocks ==16527== possibly lost: 21,940,610 bytes in 282,461 blocks ==16527== still reachable: 21,470,100 bytes in 360,304 blocks What can be done so that Inkscape makes a better effort at cleaning up its enormous memory tangle when it exits while running in valgrind? Some of the memory Inksape allocates is cleaned up, but it seems like a very high percentage of memory allocations are tacked into this complex memory structure, and inside valgrind the whole ball of yarn is just dropped on the floor when the program reaches the final exit(), rather than being unwound in an orderly fashion. (In theory GC may be cleaning this up better, but I'm not sure how we can really know, since valgrind cannot tell us.) Could somebody who understands these parts of Inkscape PLEASE clean up this mess, so that in future when "_INKSCAPE_GC==disable" Inkscape will unwind its memory structures before exiting? At the very least we will learn after this unwinding what memory is still left, and that will be the result of existing bugs in the code. Once we obtain a baseline inkscape that is usable once again in valgrind, we can reasonably expect that by using valgrind developers will be able to catch the memory problems they may introduce. Sadly that is far from true now, what with so many thousands of lines of background noise in the log files to slog through. Admittedly some of the lines in valgrind's log file do come from valgrind issues, but the ones I know about can be removed with: cat >wcslen_sse2.supp <<EOD { wcslen1 Memcheck:Addr8 fun:__wcslen_sse2 fun:* } { wcslen2 Memcheck:Cond fun:__wcslen_sse2 fun:* } { iffyinflate Memcheck:Cond fun:inflateReset2 fun:inflateInit2_ obj:* } EOD valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15 --show-reachable=yes --suppressions=./wcslen_sse2.supp --log-file=/tmp/vgfi.log src/inkscape which improves the output to: --16527-- used_suppression: 208319 wcslen1 --16527-- used_suppression: 142 wcslen2 --16527-- used_suppression: 330 iffyinflate ==16527== ==16527== ERROR SUMMARY: 97190 errors from 13437 contexts (suppressed: 208791 from 656) I understand that there may be other problems in some libraries which are called, but from the contents of the log file it looks like the majority of the loose ends were directly created in Inkscape. (And we can use valgrind suppression files, as above, to silence the unfixable library problems.) Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

4 3

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

Re: [Inkscape-devel] Bug Hunt for 0.91
by Bryce Harrington 18 Mar '14

18 Mar '14

Current stats: Bug Hunt Goal: 500 points Current: 381 points Pts Bug Date Assignee Description ------------------------------------------------------------------------ 9 1280684 2/22 Alvin Penner changing doc units with viewbox defined 9 1278645 2/22 David Mathog Image handling corrupts EMF/WMF output 9 1171109 2/20 insaner crash on cut n paste, or alt+scroll.. 6 1258473 2/13 Alvin Penner trunk: ink2canvas for stroked objects fails 6 1250250 2/07 David Mathog WMF/EMF open misplaces drawing 9 168695 1/28 Martin Owens Crash when undoing while mouse button pressed 6 1272119 1/27 apenner Poor rendering after 2geom update 6 1268778 1/25 jazzynico Move cursor disappears 3 1266308 1/15 apenner bbox dotted lines not visible if overlapped 9 1256449 1/15 Tavmjong Bah Clipped groups lose clipping when exporting 6 1268778 1/15 JazzyNico Move cursor disappears 3 1239779 1/14 Martin Owens symbol preview no longer updates 6 1253110 1/12 Johan E. Wrong intersection on circles at 45° (rev >= 12594) 6 1251405 1/10 mathog btool hitting command line limit on XP/Mingw/Msys 9 1255791 1/10 Martin Owens crash drag deleting guides 9 1257417 1/09 Martin Owens crash removing ID from object 9 1230241 1/09 Martin Owens crash for text with empty font-family 9 1258815 1/08 Kris crash after using Edit nodes icon twice 3 1255764 1/08 Bryce on screen snap message says UNDEFINED 9 1192023 1/08 Martin Owens Use elements removed when grouping 9 168695 1/08 Martin Owens crash when undoing 6 1247324 1/06 Jabiertxof optimized transforms do not propagate 9 1265556 1/04 JazzyNico plain svg export broken for filter 3 1057494 1/04 JazzyNico text hidden with "Remove Manual Kerns" 6 1262146 1/04 apenner persistent offset when scaling object On Tue, Jan 28, 2014 at 09:13:11PM -0800, Bryce Harrington wrote: > Pts Bug Date Assignee Description > ------------------------------------------------------------------------ > 9 168695 1/28 Martin Owens Crash when undoing while mouse button pressed > 6 1272119 1/27 apenner Poor rendering after 2geom update > 6 1268778 1/25 jazzynico Move cursor disappears > > 3 1266308 1/15 apenner bbox dotted lines not visible if overlapped > 9 1256449 1/15 Tavmjong Bah Clipped groups lose clipping when exporting > 6 1268778 1/15 JazzyNico Move cursor disappears > 3 1239779 1/14 Martin Owens symbol preview no longer updates > 6 1253110 1/12 Johan E. Wrong intersection on circles at 45° (rev >= 12594) > 6 1251405 1/10 mathog btool hitting command line limit on XP/Mingw/Msys > > 9 1255791 1/10 Martin Owens crash drag deleting guides > 9 1257417 1/09 Martin Owens crash removing ID from object > 9 1230241 1/09 Martin Owens crash for text with empty font-family > 9 1258815 1/08 Kris crash after using Edit nodes icon twice > 3 1255764 1/08 Bryce on screen snap message says UNDEFINED > 9 1192023 1/08 Martin Owens Use elements removed when grouping > 9 168695 1/08 Martin Owens crash when undoing > 6 1247324 1/06 Jabiertxof optimized transforms do not propagate > > 9 1265556 1/04 JazzyNico plain svg export broken for filter > 3 1057494 1/04 JazzyNico text hidden with "Remove Manual Kerns" > 6 1262146 1/04 apenner persistent offset when scaling object > > Bryce > > > > Pts Bug Date Assignee Description > > ------------------------------------------------------------------------ > > 3 1266308 1/15 apenner bbox dotted lines not visible if overlapped > > 9 1256449 1/15 Tavmjong Bah Clipped groups lose clipping when exporting > > 6 1268778 1/15 JazzyNico Move cursor disappears > > 3 1239779 1/14 Martin Owens symbol preview no longer updates > > 6 1253110 1/12 Johan E. Wrong intersection on circles at 45° (rev >= 12594) > > 6 1251405 1/10 mathog btool hitting command line limit on XP/Mingw/Msys > > > > 9 1255791 1/10 Martin Owens crash drag deleting guides > > 9 1257417 1/09 Martin Owens crash removing ID from object > > 9 1230241 1/09 Martin Owens crash for text with empty font-family > > 9 1258815 1/08 Kris crash after using Edit nodes icon twice > > 3 1255764 1/08 Bryce on screen snap message says UNDEFINED > > 9 1192023 1/08 Martin Owens Use elements removed when grouping > > 9 168695 1/08 Martin Owens crash when undoing > > 6 1247324 1/06 Jabiertxof optimized transforms do not propagate > > > > 9 1265556 1/04 JazzyNico plain svg export broken for filter > > 3 1057494 1/04 JazzyNico text hidden with "Remove Manual Kerns" > > 6 1262146 1/04 apenner persistent offset when scaling object > > > > > > On Fri, Jan 10, 2014 at 01:11:57PM -0800, Bryce Harrington wrote: > > > Quite a busy week! Another 63 points worth of bugs squished: > > > > > > 9 1255791 2014-01-10 Martin Owens crash drag deleting guides > > > 9 1257417 2014-01-09 Martin Owens crash removing ID from object > > > 9 1230241 2014-01-09 Martin Owens crash for text with empty font-family > > > 9 1258815 2014-01-08 Kris crash after using Edit nodes icon twice > > > 3 1255764 2014-01-08 Bryce on screen snap message says UNDEFINED > > > 9 1192023 2014-01-08 Martin Owens Use elements removed when grouping > > > 9 168695 2014-01-08 Martin Owens crash when undoing > > > 6 1247324 2014-01-06 Jabiertxof optimized transforms do not propagate > > > > > > Inkscape's changelog for this past week shows a lot more awesome cleanup > > > work underway that doesn't show up on this list, including warnings > > > fixes and translation updates. > > > > > > Bryce > > > > > > > Today three more regression bugs were fixed: > > > > > > > > 9 1265556 2014-01-04 JazzyNico plain svg export broken for filter > > > > 3 1057494 2014-01-04 JazzyNico text hidden with "Remove Manual Kerns" > > > > 6 1262146 2014-01-04 apenner persistent offset when scaling object > > > > > > > > Bryce > > > > > > > > On Sun, Dec 29, 2013 at 04:15:54PM -0800, Bryce Harrington wrote: > > > > > Welcome to the first bug hunt for the 0.91 release. This hunt focuses > > > > > on regression bugs. > > > > > > > > > > Traditionally, we specify a point target for us to reach, and award us > > > > > points based on the severity of the bug: 3, 6, 9, or 12 points for low, > > > > > medium, high, and critical. This bug hunt's goal is 500 points worth of > > > > > bugs from the following list: > > > > > > > > > > http://tinyurl.com/bughunt91a > > > > > > > > > > You'll note a few dozen regressions were already fixed, so we'll count > > > > > that as a (207 point) headstart on the effort. Here's a couple more > > > > > links to list only the open or closed bugs: > > > > > > > > > > http://tinyurl.com/bughunt91a-open > > > > > http://tinyurl.com/bughunt91a-closed > > > > > > > > > > [I'll write a launchpadlib script to calculate the score from the latter > > > > > list, unless someone's ambitious and beats me to it!] > > > > > > > > > > We only give points for true bug fixes - not bugs simply closed due to > > > > > being dupes, invalid, works-for-me, or whatnot. Once the bug is fixed > > > > > in the mainline branch, set its status to Fix Committed, and it'll tally > > > > > as a fixed regression. > > > > > > > > > > Bug Hunt Goal: 500 points > > > > > Current: 207 points > > > > > > > > > > If you're not a developer, you can still help by seeing if you can > > > > > reproduce the bug yourself, and posting your findings. > > > > > > > > > > If you have an idea on how to fix the bug, but don't have the time to do > > > > > it yourself, then outlining your thoughts on the bug may help junior > > > > > developers pick it up and implement the changes. > > > > > > > > > > If you're an experienced developer, consider posting an invitation to an > > > > > IRC bug party for the time period you'll be working, if you're willing > > > > > to help pilot junior developers and sponsor their patches. > > > > > > > > > > I will be posting scoring updates a couple times a week until we're > > > > > done. > > > > > > > > > > Bryce > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > Rapidly troubleshoot problems before they affect your business. Most IT > > > > > organizations don't have a clear picture of how application performance > > > > > affects their revenue. With AppDynamics, you get 100% visibility into your > > > > > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > > > > > _______________________________________________ > > > > > Inkscape-devel mailing list > > > > > Inkscape-devel(a)lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > > > ------------------------------------------------------------------------------ > > > > Rapidly troubleshoot problems before they affect your business. Most IT > > > > organizations don't have a clear picture of how application performance > > > > affects their revenue. With AppDynamics, you get 100% visibility into your > > > > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > > > > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > > > > _______________________________________________ > > > > Inkscape-devel mailing list > > > > Inkscape-devel(a)lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > ------------------------------------------------------------------------------ > > > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > > > Learn Why More Businesses Are Choosing CenturyLink Cloud For > > > Critical Workloads, Development Environments & Everything In Between. > > > Get a Quote or Start a Free Trial Today. > > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Inkscape-devel mailing list > > > Inkscape-devel(a)lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > ------------------------------------------------------------------------------ > > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > > Learn Why More Businesses Are Choosing CenturyLink Cloud For > > Critical Workloads, Development Environments & Everything In Between. > > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 4

Ungrouping switches
by Krzysztof Kosiński 12 Mar '14

12 Mar '14

This is related to https://bugs.launchpad.net/inkscape/+bug/1001756 The ungrouping code was treating svg:switch like groups. Is this the correct behavior? (For the time being, I modified it to ignore groups.) We don't use svg:switch in Inkscape-generated SVG at the moment, so this is relevant only to externally authored content. Regards, Krzysztof

3 6

Viewport, filters, and Inkscape code structure: help needed
by Tavmjong Bah 06 Mar '14

06 Mar '14

I am struggling a bit with the overall structure of Inkscape's code as I work on getting filter regions implemented correctly. This is how I understand the current structure to work: XML Tree: This represents the actual document. SP Tree: This is an expanded tree. For example: <defs> <rect id="myRect"/> </defs> <use xlink:href="#myRect"/> has two SPRect instances, one for the <rect> in the <defs> section and one generated by the <use> element. The allows for things such as style cascading and for different dimensions when the rectangles size is expressed in percent of the viewport (and there are multiple viewports in one document). Markers and symbols may also have multiple instances generated. The SP tree includes print functions used by the EMF, WMF, and TeX exporters. Other exporters (including Cairo PDF and PS) are independent of the SP and NR trees. NR Tree (e.g. Cairo Renderer): This is an expanded tree created for on-screen rendering. (Silly questions: what does NR mean?, what does 'arena' mean?) Now we come to filters. A filter can be applied to multiple objects. It's coordinates can be expressed in terms of the current viewport or the bounding box of the object that references it. In both cases, a filter's absolute coordinates can be different when applied to different objects. At the moment, only the bounding box case is handled and it is handled in the NR Tree. The NR tree doesn't know about the viewport but the SP tree does so I've tried to add code to handle the coordinates expressed in terms of a viewport into the SP tree. It seems more natural to handle coordinates in the SP tree as the SP print functions and other exporters can take advantage of these dimensional calculations. This works, kind of. There are a couple of problems: 1. The update functions of the filter primitives are not called. This can be fixed by adding explicit calls from SPFilter::update (following the model in the SPGroup update function). 2. The filter update function is only called once, at the beginning of the update process. So if a document has more than one viewport (due to an embedded SVG, for example), the filter coordinates are not updated for the second viewport. (This is unlike the <use> element case.) It seems my choices for fixing filter regions for viewport based dimensions is to either follow the <use> element example, and have instances of the filter element for each use of the element or to move all coordinate handling to the NR tree (after making the viewport available in the NR tree). The former, I think, is more desirable, but the latter may be easier. Any thoughts? Thanks, Tav

3 3

Casting-macro replacement
by Markus Engel 05 Mar '14

05 Mar '14

Hi there, in r13061 I added two template functions in order to replace the tools' casting macros. You can see them in action in widgets/pencil-toolbar.cpp:110. I also added some compile-time checking there which can be uncommented later. As I just stumbled across this. In order to build clang from its svn source, you need a c++11-enabled compiler: "This is expected to be the last release of LLVM which compiles using a C++98 toolchain. We expect to start using some C++11 features in LLVM and other sub-projects starting after this release. That said, we are committed to supporting a reasonable set of modern C++ toolchains as the host compiler on all of the platforms. This will at least include Visual Studio 2012 on Windows, and Clang 3.1 or GCC 4.7.x on Mac and Linux. The final set of compilers (and the C++11 features they support) is not set in stone, but we wanted users of LLVM to have a heads up that the next release will involve a substantial change in the host toolchain requirements." Should I proceed replacing the casting-macros like this? Any suggestions? Regards, Markus

5 13