May 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

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

Undefined but declared hash<> template causing C++11 trouble
by Johan Engelen 25 Jun '14

25 Jun '14

Hi Krzysz, The following lines in ui/tool/node.h are causing trouble with gcc 4.9 C++11: #if HAVE_TR1_UNORDERED_SET namespace std { namespace tr1 { template <typename N> struct hash< Inkscape::UI::NodeIterator<N> >; } } #endif Is it OK to remove those? If I comment them out, all seems to work fine. I cannot find the specialization definition anywhere, so seems only a fwd decl? regards, Johan

4 5

Re: [Inkscape-devel] Rejuvenated build system for Mac OS X
by frizzlefry 19 Jun '14

19 Jun '14

Yes, the osxmenu branch is looking really fantastic. I believe though that those builds are hosted on su_v’s personal drobox account, and considering the amount of traffic this thread has been getting (it’s over 10k views now), it may be better to share them as torrents or mirror them somewhere else so su_v’s account doesn’t get hammered. On Apr 18, 2014, at 5:09 AM, duvrai [via Inkscape] <ml-node+s13n4970261h31@...2730...> wrote: > OK, I just found out about the new development on native Inkscape for Mac. > You can even download the latest unstable builds! > It's all here: > https://code.launchpad.net/~suv-lp/inkscape/osxmenu > > If you reply to this email, your message will be added to the discussion below: > http://inkscape.13.x6.nabble.com/Mac-OS-X-Mountain-Lion-x86-64-packaging-of… > To unsubscribe from Mac OS X Mountain Lion x86_64 packaging of 0.48.4, click here. > NAML -- View this message in context: http://inkscape.13.x6.nabble.com/Mac-OS-X-Mountain-Lion-x86-64-packaging-of… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

4 7

Notes from LGM Inkscape Meeting
by unknown＠example.com 14 Jun '14

14 Jun '14

Hi all, We had a very good meeting this morning. Nine (9!) Inkscapers were present (partially thanks to the Inkscape development fund). Here is a list of those present: Martin Owen/doctormo (barcode extension, Python, C++) Joakim Verona (artwork, Inkscape with emacs, d-bus, interest in embedded Inkscape) Krzysztof Kosiński (Clipboard, Cairo renderer, boolean path operations) Gémy Cédric/pygmee (extensions, Python, documentations) Sirko Kemter (LGM Host, Inkscape trainer) Elisa de Castro Guerra (documentation, translations) Ryan Lerch (Redhat user) the Adib (translation, Cairo, interest in PDF output) Myself Here are some notes I took from the session merged with some notes from Elisa (thanks!). We covered a lot of stuff. Let me appoligize to those present if I get some details mixed up. 1. Community Development The Inkscape community appears to be quite weak compared to other projects. We discussed a variety of reasons for this and possible solutions. * The community appears to be quite fragmented due to multiple websites for code, bug-tracker, mailing lists, forums, etc. We should consolidate where possible. There could be better linkage between sites. The Inkscape website still needs to be expanded. For example, there is no page for translators (already fixed since our meeting, thanks Elisa and Martin!). Also, we need make sure that feature requests in the Inkscape forums get aggregated to the developers email list. Martin will try to find someone to volunteer to act as liaison. * There appears to be a lack of direction. The Inkscape board is, by design, limited to controlling Inkscape's donations and trademark. Having some kind of steering committee might be beneficial. * There is a lack of visible momentum in the project, exasperated by the long time between current releases. (We desperately NEED to get 0.91 out - as well as 0.48.5. People need to see progress.) More news articles are needed (with rapid translation). * Paid developer: Synfig hired a developer who is now paid month-to-month by crowd-funding. This has actually stimulated additional developer contributions. People see progress being made and are more likely to make their own code contributions. There are weekly updates by the developer where people see the progress being made. (This is in contrast to the prevailing view inside the Inkscape community where paid development might threaten further contributions by non-paid developers.) Blender uses a subscription system. Many communities use a voting process to select the direction of paid development. We do need to be careful, as Scribus had a bad experience with a paid developer disappearing without delivering promised code. http://libregraphicsworld.org/blog/entry/crowdfunding-for-sustainability-sy… * Extensions is a place where people can easily make contributions. We need a web page with links to contributed extensions (or host them ourselves). (BTW, Blender had 8 part-time developers but still has a very active community of people contributing extensions.) 2. Paid developer We discussed what we would want a developer to do if one were hired. Ideas were: * Animation (high profile, improve sense of forward momentum). * PDF Export (same as above). * Plug-in structure (make it easier to contribute). * Code clean-up and documentation (make it easier to contribute). * Release (get timely releases out). * Testing 3. Website Translations Several problems were identified with translating the website. Translated news is being shown twice, once in the translated language and once in English. Martin and Adib will look into fixing this (some python coding). Also, translators are not notified of news updates. Martin will assemble a list of translators and set up a "cron" job to monitor changes to the website and then notify translators when changes are detected. 4. Technical discussions: * 0.91 release: We need to get this out, even if there are a few remaining bugs. Adib will help with Windows builds. There is great demand for a GTK3 OSX build. It seems that the only hold-up is redoing the rulers as GTK3 dropped the ruler widget. Gimp has the same problem. * Testing: We need better automated testing in both rendering and in unit-tests. cxxtests is awkward to use (and nobody seems to look at it, their are many tests failing now). * Patch reviews: We need to be quicker in reviewing patches or we risk losing new devolopers. We might need to revisit our very easy access to code check-in rights. A person writing Python extensions might not be as proficient with C++. * PDF Export: We discussed various strategies for improving our export to PDF, especially focusing on CMYK. Krzysztof has some ideas for achieving this. After our meeting, we had further discussions with people from Scribus on this topic. This topic is also coupled into possibly supporting other rendering methods (e.g. GEGL). There are a couple possible solutions. One is to extend Cairo to handle color profiles. This might not be so hard as we could write out RGB but include a color profile to hand RGB to CMYK conversion. One problem is that Cairo doesn't support the color-depth we would like. The second is to write our own PDF exporter. While Scibus's PDF export code is tightly coupled to the rest of Scribus, it can serve as a good model of what we need to do. The current "recommended" way of getting good PDF CMYK files is to pass Inkscape's SVG through Scribus. This is problematic as SVG support in Scribus is behind Inkscape's. Filters are not supported in Scribus. Adib will look in to possible filter support in Scribus. * Export: Our export mechanisms needs to be unified, probably with a "visitor's" model. * Filters: Needs to be reworked to follow the model of other objects. (There are hacks needed now to get the rendering done correctly.) * Multipage SVG: We discussed ways to use groups (layers) to handle multipage SVGs. The layer dialog might be modified with some added Inkscape name-space attributes to have groups of layers of which selecting one will hide the others in the group. (This would make editing JessyInk presentations much easier!) Martin has volunteered to put a plan together. * Remove need for "id" attributes. (Krzysztofv has an idea on this.) * Excessive signaling. Why does dragging a gradient handle cause closed dialogs to call style handling code? * Redhat/Gnome/Fedora had a series of requests already forwarded to the mailing list. * BZR migration: BZR is no longer under development.

5 6

GSOC status report - Better support for SVG paints
by Tomasz Boczkowski 13 Jun '14

13 Jun '14

Hi! GSOC 2014 program started a week ago. I would like to describe, what I have done since then in my project. The branch, I'm doing my development in is lp:inkscape/~penginsbacon/ inkscape/svg-paints-support. Week 1: 1) The main objective was to refactor c-style UI widgets to c++ and gtkmm. I managed to fully port SPColorSlider. It is now called Inkscape::UI::Widget::ColorSlider. The class works with both GTK2 and GTK3 libraries. Sadly, this partial task took me longer than I expected. Understanding gobject object model was quite difficult. 2) The topic of refactoring ColorSelector and related classes is being actively discussed with Jon A. Cruz at the mailing list. He mentioned possible problems with Gtkmm widgets that I was not aware of before. 3) Simple changes to SPPattern class are in progress. They consist in: a) moving c-like functions to class methods b) getting rid of GSList c) replacing gchar* by Glib::ustring d) converting *_set fields from guint to bool e) converting giuint fields to enums. Tomasz

5 7