- Inkscape Devel - Inkscape Mailman

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

Win64: feature complete
by Johan Engelen 03 Jun '14

03 Jun '14

Hi all, A quick note to let you know that aspell is now added to devlibs64, so that the 64bit version of Inkscape on Windows is now feature complete (i.e. same features as 32bit version) Jay! Johan

3 3

Method to duplicate a SPDocument?
by mathog 01 Jun '14

01 Jun '14

If there is an existing method for making a copy of an SPDocument, what is it called? Resolving bug 1318657, without introducing other problems, seems to require that the clipboard be replicated, and all actions occur on the replica, which is then thrown away. See comments 8 and 9 https://bugs.launchpad.net/inkscape/+bug/1318657 Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 2

Removal of -inkscape-font-specification ?
by Tavmjong Bah 01 Jun '14

01 Jun '14

Hi, I would like to propose the removal of the Inkscape specific -inkscape-font-specification property. This property was added in 2007 in an attempt to allow Inkscape to handle more font faces for a given font family than allowed by CSS.[1] It relied on Pango being changed to support this. In the intervening seven years, Pango has not changed nor does it seem likely it ever will. There doesn't appear to really be a need to expand on what CSS does already (and any SVG files that would use such a feature would not be viewable correctly in browsers). Inkscape (trunk) already supports, for example, all nine font faces of DejaVu Sans. Support for the font-variant features of CSS Fonts Module Level 3[2] would allow access to variants within a single font file which seems to satisfy the need that -inkscape-font-specification was meant to address. Font factories already have moved to put variants inside a single font file (vs. keeping them in separate files). See for example the bug (from 2004) about Adobe Caslon[3] with the long list of variants and the current OTF files from Adobe where the Small Caps, Alternative, and Swash variants are included in the regular files.[4] At the moment, -inkscape-font-specification duplicates the information already stored in other font related properties. There is a cost in this duplication, not only in increased file size but also in code maintenance. Keeping -inkscape-font-specification matching the other font properties is a source of bugs. It is currently making proper quoting of font-family names in font-fallback lists more difficult to fix. The actual changes needed to remove -inkscape-font-specification are straightforward and effect a few lines in about seven or eight files. No functionality would be lost as the property is completely redundant with the other font related properties. Tav [1] https://bugs.launchpad.net/inkscape/+bug/169973 [2] http://www.w3.org/TR/css3-fonts/#font-variant-prop [3] https://bugs.launchpad.net/inkscape/+bug/165521 [4] http://www.myfonts.com/fonts/adobe/caslon/buy.html

2 2

New PreviewHolder and swatches dialog design.
by Tomasz Boczkowski 28 May '14

28 May '14

Hi! I have designed a new class layout for PreviewHolder. It's functionality is illustrated at [1] Because the new widget should support not only rendering paints, but also glyphs and symbols, a flexible architecture is needed. I've choosen MVC approach, heavily based on Qt MV model design [2]. It is shown at [3]. In the upper part of the picture there are generic model and view classes. The lower part shows the application in swatches dialog. Model is organized as a hierarchy of lists. Qt documentation explains similar hierarchy of grids [4]. It enables navigating and iterating through the structure and defined signals when items are inserted, moved or deleted. Model class itself does not contain data (classes that inherit it do) and it's methods do not provide access to data items. Model index is array index generalization for hierarchical structures. PreviewHolder belongs to the "View" part. It is the widget that displays items categories and places the preview tiles. To make things work it needs a model and a means to display (and access) model data. The latter is provided by TileRenderers. TileRenderers can render images associated with model data. When clicked they send signals. How do TileRenderers access to data contained in model, while Model class does not provide access to them? They are all constructed by a TileRendererFactory. Concrete factories find appropriate data items by ModelIndex, and initialize concrete TileRenderers with it. They also bind tile renderer signals upon construction. The example shows the use of PreviewHolder in swatches dialog. Displayed items are paints. They are stored in PaintsModel. This class represents paint servers stored in document and built-in ones. It reacts to changes in document, updates it's entries and sends generic model signals. The model consists of PaintItems, that represent paints servers and provide access to SPPaintServer objects. PaintTileRenderer just fills it's content with pattern. Swatches dialog besides being a dialog, defines a slot that is executed when a tile renderer is clicked. It invokes apropriate SVG tree actions to set current object fill and stroke or execute "paint properties" dialog. TileRenderer can be implemented as plain class or it can inherit Gtk::Widget. The second solution would mean easier support for mouse and D&D events, but I'm not sure if it would affect performance (gobject construction, storing Gdk::Windows, initializing cairo context for each widget in GTK2). We will have several hundreds of those objects. Did you encounter any issues with Gtk performance? Which solution do you recommend? [1] https://www.dropbox.com/s/7nbg1uzk1sal2kn/new_swatches_ui.png [2] http://qt-project.org/doc/qt-4.8/model-view-programming.html [3] https://www.dropbox.com/s/r5ph6tgp5halal6/PreviewHolder.pdf [4] http://qt-project.org/doc/qt-4.8/model-view-programming.html#parents-of-ite… Regards, Tomasz

1 1

New video for the LPE Fillet-Chamfer
by Jabiertxo Arraiza Cenoz 28 May '14

28 May '14

Hi to all. I just release a new video for the LPE Fillet-Chamfer. Now have simplified interface and more features and bugfixes. https://www.youtube.com/watch?v=wJKzGhJULfc Thanks to Nathan, Liam, Josh, SUV, Mc- and all give feedback!

1 0

New LPE, New Video. Fillet/Chamfer
by Jabiertxo Arraiza Cenoz 28 May '14

28 May '14

Hi to all. Here is a video showing my new LPE. The branch is here[1].The video here[2]. Thanks to Josh Andler for give me the idea Also thanks very much to suv for the feedback and time inverted on it. And a special thanks to Liam P. White, without his help the LPE need a lot of hours to be.. or not to be. Bye, Jabiertxo. [1] https://code.launchpad.net/~inktxof/inkscape/fillet-chamfer [2] https://www.youtube.com/watch?v=HdsxhXPksgo

5 17

Change in pixels per inch?
by Tavmjong Bah 27 May '14

27 May '14

Hi TimeWaster and Nick, Alvin Penner has suggested that I contact both of you about a change to Inkscape I am pushing for: Currently Inkscape transforms non-pixel units (e.g 'in', 'cm') using the ratio 90 pixels per inch. This ratio is hinted at in SVG 1.1 but not explicitly defined (someday I'll blog about the history of this). CSS 2.1 does explicitly defined the ratio to be 96 pixels per inch, a standard that all web browsers as well a Batik have followed for many years. I recently proposed that in SVG one should be allowed to set this ratio but that idea was quickly rejected by the standards group. Previous to Inkscape 0.91 all dimensions inside of Inkscape were stored only as pixels values (despite allowing the user to enter dimensions in other units). As long as one did not import SVGs from other sources the ratio between px and in was not all that important. With 0.91, one can optionally set font-size to be output in points. To ensure consistency with what is rendered in Inkscape and what is displayed by other SVG renderers we should move to the standard 96 pixels per inch per CSS2.1. To make the change, two files must be modified: share/extensions/inkex.py share/ui/units.xml and probably the default export resolution should also be changed in preferences. Alvin is afraid this will cause trouble in the world of desktop cutters and plotters. Do you see this as a problem? Thanks, Tav BTW, the 0.91 release notes suggest that extensions relying on units other than pixels were already broken by the work on units.

4 9

Re: [Inkscape-devel] Widget c++-sification
by Tomasz Boczkowski 25 May '14

25 May '14

Resending: original message was send accidentally off-list. >> A safe way to mitigate many of the C vs C++ issues with Gtkmm is to keep a proper logical separation between Gtkmm UI objects and the functionality they trigger or state they manifest. The bulk of code ends up in plain C++ classes, while the Gtkmm widgets merely provide a thin layer to expose >> in the 'proper' manner. That might including moving certain functionality out of the widget classes themselves. I see your point. Could you please name some inkscape UI classes that preserve the separation? I would like to go on with SPColorSelector refactoring. In Inkscape color can be selected using one of two widgets: sp-color-wheel-selector, sp-color-icc-selector. They share common functionality in sp-color-selector. Currently there are six structures consisting of both Gobjects and c++ classes. I made a simplified diagram, listing possible options for refactoring [1]. 1) ColorSelector widgets contain a reference to their state (ColorSelector). It is accessible via getColorSelector() method. Optional ColorSelectorWidget abstract class provides the method. Parent UI component would initialize color selector widgets in ctor. Reference to widget would be kept in ctor only. Parent class would contain a pointer to widget state, returned by getColorSelector(). 2) Double inheritance. ColorSelector provides widget state. Concrete implementations inherit ColorSelector and aproppriate Gtk::Widget. 3) Full wrapper. Color selector widgets contain reference to their state and have full set of thin wrapper methods. They only call corresponding methods in ColorSelector. Which is the best? What is the suggested naming and namespacing of mentioned classes? Which of the options fits the separation between gtkmm and functionality best? [1] https://www.dropbox.com/s/nvie03p9ee9r8ry/colorSelector.pdf Regards, Tomasz On Sat, May 24, 2014 at 12:41 PM, Tomasz Boczkowski <penginsbacon@...400...>wrote: > >> A safe way to mitigate many of the C vs C++ issues with Gtkmm is to > keep a proper logical separation between Gtkmm UI objects and the > functionality they trigger or state they manifest. The bulk of code ends up > in plain C++ classes, while the Gtkmm widgets merely provide a thin layer > to expose > > >> in the 'proper' manner. That might including moving certain > functionality out of the widget classes themselves. > > I see your point. Could you please name some inkscape UI classes that > preserve the separation? > > I would like to go on with SPColorSelector refactoring. In Inkscape color > can be selected using one of two widgets: sp-color-wheel-selector, > sp-color-icc-selector. They share common functionality in > sp-color-selector. Currently there are six structures consisting of both > Gobjects and c++ classes. > > I made a simplified diagram, listing possible options for refactoring [1]. > 1) ColorSelector widgets contain a reference to their state > (ColorSelector). It is accessible via getColorSelector() method. Optional > ColorSelectorWidget abstract class provides the method. Parent UI > component would initialize color selector widgets in ctor. Reference to > widget would be kept in ctor only. Parent class would contain a pointer to > widget state, returned by getColorSelector(). > 2) Double inheritance. ColorSelector provides widget state. Concrete > implementations inherit ColorSelector and aproppriate Gtk::Widget. > 3) Full wrapper. Color selector widgets contain reference to their state > and have full set of thin wrapper methods. They only call corresponding > methods in ColorSelector. > > Which is the best? What is the suggested naming and namespacing of > mentioned classes? > Which of the options fits the separation between gtkmm and functionality > best? > > [1] https://www.dropbox.com/s/nvie03p9ee9r8ry/colorSelector.pdf > > > > On Wed, May 21, 2014 at 8:21 PM, Jon A. Cruz <jon@...18...> wrote: > >> On Wed, May 21, 2014, at 10:31 AM, Tomasz Boczkowski wrote: >> >> Thank you for the answer. >> >> >>Also, take care on what widgets you are looking at. We have a few >> groupings in our source tree that are meant to stay C. >> >> I started with src/widgets/sp-color-slider. I plan to continue with >> widgets related to fill and stroke dialog (sp-color-notebook, >> sp-color-scales, sp-color-wheel-selector etc.). Are they safe to port? >> >> >> >> Those should be OK... but in the 'proper' manner. That might including >> moving certain functionality out of the widget classes themselves. >> *Additionally* those I recognize as some of the first files I poked at when >> I initially joined Inkscape (before the project had its name). They're >> probably quite outdated by this point. >> >> Then also keep in mind that "sp" stands for Sodipodi, so when you move >> files you can drop such. Just be sure to do it in a source-control friendly >> way that won't break history. :-) >> >> >> >> >>>> 4) Should child widgets be stored as pointers as in glyph.h or >> directly as in text-edit.h? >> >> Which file are you referencing as "glyph.h"? >> >> src/ui/dialog/glyphs.h >> >> >> Ahh, that's an interesting question. >> >> For widgets, the design and intent of Gtkmm is to place children via new >> + Gtk::manage(). That ensures consistent object lifetimes and helps reduce >> memory leaks. For even stronger encapsulation often it's better to not list >> pointers as members in the public .h file, but keep them all to setup in >> the constructor. Since you won't have to delete them, you don't have to >> track them... for those cases where you set up events and handlers then add >> the child. That also goes on to event driven programming, and fewer bugs >> once you wrap your head around it. >> >> -- >> Jon A. Cruz >> jon@...18... >> >> >> ------------------------------------------------------------------------------ >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. >> Get unparalleled scalability from the best Selenium testing platform >> available >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> >> >

2 2

New LPE, New Video. Fillet/Chamfer
by Jabiertxo Arraiza Cenoz 21 May '14

21 May '14

Hi Nathan, i have problems whith my mail and get your reply searching by web the mailing list. Thanks very much for your help! Regards, Jabier. ################################################################ Hi Jabiertxo, There are various functions for this, the technical term is 'arc length', you can either compute a specific curves' total arc length (length), get an sbasis which maps time to arc length(arcLengthSb), or you can reparameterise a curve by arc length (arc_length_parameterization). There was an inverse arc length to time function somewhere too, but I can't remember what it's called. I think the easiest way to get what you want is roots(arcLengthSb(B) - desiredLength) which will return all the positions on B that are desiredLength from the start. njh On Mon, May 19, 2014 at 08:59:19PM +0200, Jabiertxo Arraiza Cenoz wrote: > Hello again. > Thanks to LiamW i undertand the time in bezier curves is influenced by > his curvature. Now i have a problem i want to select a time value at > specific distance. Is posibol actualy? > > Thanks, Jabier.

1 0