January 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

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

Why is the position of this line of code so touchy?
by mathog 28 Feb '14

28 Feb '14

In the files in src/display there are many instances of this Inkscape::DrawingContext::Save save(dc); First thing, I don't understand the syntax. What does the lower case "save" in that line indicate? The only places "::Save save(" appear in the source code are instances of this line. Secondly, it acts strangely. Moving it around breaks graphics for some reason that escapes me. For instance this: Inkscape::DrawingContext::Save save(dc); //PROBLEM LINE dc.transform(aff); double thickness = decorateItem(dc, aff, phase_length); dc.setLineWidth(thickness); dc.strokePreserve(); dc.newPath(); results in mangled graphics (text decoration drawn as if with a very thick line, but in what appears to be the correct location), whereas moving the first two lines above into double DrawingText::decorateItem(DrawingContext &dc, Geom::Affine const &aff, double phase_length) as the first two lines of that method results in normal graphics (text decoration drawn with the expected line thickness). That is: line1 line2 call is broken but call (inside called function) line1 line2 works. Moving "dc.setlinewidth()" from the position shown above into decorateItem() as the line before its return does not make any difference in either of these cases. decorateItem() just defines a cairo path with moveto/lineto on _ct in dc, it doesn't touch anything else in the dc. Using the debugger and stepping through showed that execution of the problem line passes through this: DrawingContext::Save::Save(DrawingContext &dc) : _dc(&dc) { _dc->save(); } in drawing-context.cpp. _dc->save() just does cairo_save(_ct); I have never seen anything quite like this when using cairo directly, that is, calling cairo_save() and cairo_restore() has never resulted in mysteriousness of this level. And that seems to be mostly what the DrawingContext does - it keeps track of (private) cairo_t *_ct; I would have thought that passing dc by reference should have made the position of the problem line before the call, or just within the called function, a moot point, but apparently not. This is so even though when the address of _ct was checked with dc.raw(), before and after the problem line, it didn't change. Whether or not the problem line was before or inside decorateItem(). Can somebody please explain what is happening here? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

4 5

Href sub-document model
by Martin Owens 28 Feb '14

28 Feb '14

Hey developers, This is the model I'm going to implement for documents to reference other documents: SPDocument { GSList *child_documents; SPDocument *parent_document; // Parent of parents until parent == NULL; SPDocument *getRootDocument(); } Then in uri-reference, check paths of existing child_documents, load the referenced document and add to child_documents. Set parent_document. That should keep things consistant. The idea here is that we'll use this to track documents referenced in <use tags> as well as <image tags> and attributes like 'marker-*: url(...);' but not for non-vector graphics used in the image tag. Thoughts? Advice? Best Regards, Martin Owens

6 23

Image Data URIs
by Martin Owens 28 Feb '14

28 Feb '14

He devs, I've been trying to read up on image tags special case, where a href will start with data: and then proceed to have data. Since I want to merge most of the sp-image logic into Inkscape::URI I need to know if data uris are something the svg spec says should only be available to image tags... or should be available to any href. The svg 1.1 spec says nothing about data uris that I could find. Any ideas? In the end, I want hrefs to be able to be loaded, processed into localised absolute references and even parsed for data if that's generic. From the same Inkscape::URI object. Does this seem sensible? I note the css url(...) handler isn't the same as the href handler; so should something be done to help those converge too? Any thoughts would be appreciated. Martin,

3 2

the Developer Education Book Campaign 2013 !
by Johan Engelen 25 Feb '14

25 Feb '14

Hello all, In an effort to give back to our developers, I hereby present to you the Developer Education Book Campaign 2013 ! We'd like to give an educational present to our most active contributors. The board has decided to buy a programming book for each of the top 10 contributors of 2013! The ranking is determined by the number of commits to trunk in the past 12 months, as calculated by Ohloh.net [1] [2]: Kris de Gussem Alex Valavanis Markus Engel Matthew Petroff Nicolas Dufour Martin Owens Tavmjong Bah Krzysztof Kosiński Sebastian Wüst Alvin Penner Thank you very much for your great work in 2013!!! These 2013 rockstars can choose from one of the following books: a) Effective C++, 3rd Ed. by Scott Meyers b) Refactoring: Improving the Design of Existing Code by Martin Fowler c) A Tour of C++ (C++11) by Bjarne Stroustrup The developer is also allowed to pass it on to the runner-up if he so wishes. Because I initiated the book campaign, I will pass (don't worry, I've already ordered my book ;). So now you might think: wait a minute..., these coders get a book on how to program... are they that bad? They are not bad; they could be even better! We all can improve our coding, and there is no shame at all in reading up and refreshing our coding skills. Every day I am reading Stroustrup's C++11 tome in the train to work, no joke! I hope you all will enjoy your present, and can perhaps share with us the best things you've learned :-) Cheers to a good start in 2014! Johan [1] http://www.ohloh.net/p/inkscape/contributors?query=&sort=commits_12_mo [2] I'm sorry if you feel this metric is unfair and skewed. We had to agree on some metric, knowing that any metric is imperfect.

8 10

patches for the bughunt waiting for some testers
by insaner 10 Feb '14

10 Feb '14

very trivial patches to test: https://bugs.launchpad.net/inkscape/+bug/1171109 comment #19 and https://bugs.launchpad.net/inkscape/+bug/1251951 comment #9 please test and provide feedback so I can check in the changes for the first one, and figure out what to do with the second one. Thanks -- View this message in context: http://inkscape.13.x6.nabble.com/patches-for-the-bughunt-waiting-for-some-t… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

3 7