- Inkscape Devel - Inkscape Mailman

gcc 4 help needed
by MenTaLguY 09 May '05

09 May '05

I've been told that line 111 of debug/logger.cpp doesn't compile with gcc 4. Could someone please give me the specific error (with all context lines, please)? -mental

2 3

English tutorials converted
by bulia byak 08 May '05

08 May '05

May 1st, 2005 — Thanks to the active help from the community, all English tutorials that we had in SVG are now converted to DocBook! From within Inkscape, they are still available as fully editable SVG which you can play with, but having the DocBook source makes it easy to produce any other formats or renditions automatically. In particular, all converted tutorials are now availble in HTML, linked from our Documentation page. What's next? We have several of the tutorials translated into several languages. Now we need to convert these to DocBook as well. Here is a page http://inkscape.org/cgi-bin/wiki.pl?TranslationInformation with details on how to translate tutorials or convert existing translations. We already have the Basic in Spanish and several French ones are being worked on; the rest are up for grabs. Pick a tutorial and make it available in your native language! -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 4

Re: Fwd: [s4-p18] [Inkscape-devel] svg2ps - Test Files
by MenTaLguY 08 May '05

08 May '05

On Sun, 2005-05-08 at 13:35, bulia byak wrote: > What I have at the moment is a couple of scripts that read the CSS2.1, > SVG1.1 and CSS3Text specs as downloaded off the w3c site, find all the > property definitions within them and automagically produce output such > as: > > /** \brief Representation of the CSS 'counter-reset' property > > Generated from "[ <identifier> <integer>? ]+ | none | inherit" > Inherit: False > Initial: none > */ > struct inkscape::style::css::counter_reset { > bool read(Glib::ustring const &str); > Glib::ustring write() const; > void set_to_initial(); > unsigned set:1; > unsigned inherit:1; > unsigned type:1; > struct inkscape::style::css::identifier { > unsigned integer_set:1; > struct css_identifier value_identifier; > struct css_integer value_integer; > }; What exactly does this sort of nested declaration mean? > std::vector<struct identifier> value_identifier; > enum {type_identifier, type_none}; > }; > 1) Where do I go from here? The simplest answer is to bundle the whole > lot into SPStyle, like we have at the moment. The problem with that is > of course that the current struct is at least 320 bytes and putting > all 160+ css properties into it would consume a significant amount of > memory in a large drawing. At the opposite end of the memory:cpu ratio > spectrum is to have no SPStyle at all and require everyone to call > read() themselves if they want a pre-parsed property. Half-way points > are of course possible too, where particularly common properties like > fill and stroke are held in SPStyle but everything else is evaluated > on each request. There are also lazy evaluation schemes which save the > results of the evaluation, and so on and so forth. My personal > favorite at the moment is to have most things lazy but a selected few > always calculated. That's probably the best long-term goal. For the short-term lumping everything into SPStyle is best because it is simple and is known to work. Longer-term I will have to get a better sense of the design before making any recommendations. Probably some sort of lazy thing backed by an associative data structure, queried by symbols (i.e. GQuark or the like) would be best. Whatever it ultimately is, the interface for lazy and non-lazy properties should remain uniform. > 2) The more fundamental question: am I even going in the right > direction? I'm replacing a simple yet difficult-to-maintain piece of > code with a complex yet zero maintainance (or close to it, anyway) > piece of code. What's the point anyway when I should only need to run > it once, then throw it away? Since the majority of properties are > simple enums, wouldn't it be easier to do it all by hand? Is this just > refactoring for its own sake, without any useful new features in > sight? (Actually that's not true; a proper implementation of shorthand > properties is notably lacking at the moment). In principle it's much better. Don't ever believe the "just once" part though. It's best to have the source specifications and the script that generates them in the source tree, and have them be authoritative. And generate the code as part of the build process. Because Things Will Change, and the last thing you want is to tempt people into manual hacking of generated code. Do see if you can hoist some of the stuff that's currently generated into non-generated superclasses though. Anything that gets repeated multiple places is screaming for refactoring. The platonic ideal is that there should only be one place in the entire codebase which is authoritative for a particular pattern of code. -mental

1 0

Re: [Inkscape-devel] Memory Problems
by Richard Kowalczyk 07 May '05

07 May '05

Results of comparing zoomed out with regular zoom: regular: memory percent: 6.6% -> 23.6% buffers/cache: 224 -> 310 zoomed out: memory percent: 5% -> 12.5% buffers/cache: 217 -> 254 The zoomed out numbers are very similar to the numbers for just previewing each file. So it appears that you are correct that the memory problem is in the renderer. On Sat, 2005-05-07 at 11:32 -0300, bulia byak wrote: > Interesting, this means that normal loading is indeed different enough > from previewing, memory-wise. We had assumed it's mostly the same, so > we didn't test multiple file loading except via previews (to my > knowledge). > > It may be that the source of the leaking is the renderer, which may > leak more memory for full-screen display than for generating previews > (even though the same renderer is used in both cases). Can you please > try one more experiment: in all your files, zoom out to minimum zoom > and save them under different names with that zoom. Then, load them > all normally one after the other into the same Inkscape instance. If > the renderer is the culprit, this should have some measurable effect > on memory consumption. > > On 5/7/05, Richard Kowalczyk <richk@...805...> wrote: > > I just tried what you suggested, and it seems to use significantly less > > memory. > > > > I had some different apps open this time, so I can't compare it exactly > > with my previous tests, but here is a rough comparison: > > > > opening all files: > > memory percent: 7% -> 45% > > buffers/cache: 214 -> 435 > > > > opening and closing the previous: > > memory percent: 5.9% -> 27.9% > > buffers/cache: 231 -> 342 > > > > inkview: > > memory percent: 3.5% -> 21.9% > > buffers/cache: 226 -> 327 > > > > inkscape preview window: > > memory percent: 5% -> 13% > > buffers/cache: 337 -> 372 > > > > So just previewing the files seems to use up significantly less memory > > than even inkview. > > > > On Sat, 2005-05-07 at 10:58 -0300, bulia byak wrote: > > > Richard, can you also try this: in the Open dialog, just select these > > > files one by one, so that a preview of each one is shown, and see if > > > there's a memory difference at the end. (Each preview loads and > > > renders the entire document.) I do remember that we fixed, at least > > > partially, the memory leaking when going through previews in this way. > > > So what you describe may be explained by: 1) our not fixing the leaks > > > completely, only partially, or 2) Inkscape using a different and > > > not-yet-fixed load path when loading the document fully than when > > > doing a preview. > > > > > > Mental, can you comment? > > > > > > > > > On 5/5/05, Richard Kowalczyk <richk@...805...> wrote: > > > > I tried doing what you suggested. I went though 26 slides, since it > > > > seemed to be enough to get an indication of the behavior. > > > > > > > > (Just to clarify - I opened the next one (from within the current one), > > > > then closed the current one - if I had closed the current one first, the > > > > memory would be cleared) > > > > > > > > The memory used seems to be roughly equivalent between inkscape and > > > > inkview, although inkview does use less. Either way though, the memory > > > > keeps going up as I go through more slides. > > > > > > > > I attached three files to this email - the result of doing the command: > > > > > > > > ps aux | grep -e "inkview" >> memory.txt; free -m >> memory.txt > > > > > > > > for three cases: > > > > > > > > memory_inkview.txt: after I clicked the right arrow to advance each > > > > slide, I ran the command. > > > > > > > > memory_one_per_time.txt: I did what you suggested, and opened each file > > > > in inkscape, then closed the old one, running the command for each new > > > > file. > > > > > > > > memory_all_open.txt: I opened each file in inkscape, but didn't close > > > > the previous file, so by the end, I had 26 files open at once. I ran > > > > the command after each file was opened. > > > > > > > > Thanks for your help, > > > > Rich. > > > > > > > > On Thu, 2005-05-05 at 19:38 -0300, bulia byak wrote: > > > > > On 5/5/05, Richard Kowalczyk <richk@...805...> wrote: > > > > > > I will be glad to do anything else that anyone thinks will help explain > > > > > > the memory usage. > > > > > > > > > > Can you try loading these same files in turn (i.e. closing the > > > > > previous one when loading the next) into Inkscape instead of Inkview > > > > > and see if there is a noticeable difference? > > > > > > > > > -- > > > > Richard Kowalczyk <richk@...805...> > > > > > > > > > > > > > > > > > > > > -- > > Richard Kowalczyk <richk@...805...> > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. > > Get your fingers limbered up and give it your best shot. 4 great events, 4 > > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > -- Richard Kowalczyk <richk@...805...>

2 1

Re: [Inkscape-devel] Memory Problems
by Richard Kowalczyk 07 May '05

07 May '05

I just tried what you suggested, and it seems to use significantly less memory. I had some different apps open this time, so I can't compare it exactly with my previous tests, but here is a rough comparison: opening all files: memory percent: 7% -> 45% buffers/cache: 214 -> 435 opening and closing the previous: memory percent: 5.9% -> 27.9% buffers/cache: 231 -> 342 inkview: memory percent: 3.5% -> 21.9% buffers/cache: 226 -> 327 inkscape preview window: memory percent: 5% -> 13% buffers/cache: 337 -> 372 So just previewing the files seems to use up significantly less memory than even inkview. On Sat, 2005-05-07 at 10:58 -0300, bulia byak wrote: > Richard, can you also try this: in the Open dialog, just select these > files one by one, so that a preview of each one is shown, and see if > there's a memory difference at the end. (Each preview loads and > renders the entire document.) I do remember that we fixed, at least > partially, the memory leaking when going through previews in this way. > So what you describe may be explained by: 1) our not fixing the leaks > completely, only partially, or 2) Inkscape using a different and > not-yet-fixed load path when loading the document fully than when > doing a preview. > > Mental, can you comment? > > > On 5/5/05, Richard Kowalczyk <richk@...805...> wrote: > > I tried doing what you suggested. I went though 26 slides, since it > > seemed to be enough to get an indication of the behavior. > > > > (Just to clarify - I opened the next one (from within the current one), > > then closed the current one - if I had closed the current one first, the > > memory would be cleared) > > > > The memory used seems to be roughly equivalent between inkscape and > > inkview, although inkview does use less. Either way though, the memory > > keeps going up as I go through more slides. > > > > I attached three files to this email - the result of doing the command: > > > > ps aux | grep -e "inkview" >> memory.txt; free -m >> memory.txt > > > > for three cases: > > > > memory_inkview.txt: after I clicked the right arrow to advance each > > slide, I ran the command. > > > > memory_one_per_time.txt: I did what you suggested, and opened each file > > in inkscape, then closed the old one, running the command for each new > > file. > > > > memory_all_open.txt: I opened each file in inkscape, but didn't close > > the previous file, so by the end, I had 26 files open at once. I ran > > the command after each file was opened. > > > > Thanks for your help, > > Rich. > > > > On Thu, 2005-05-05 at 19:38 -0300, bulia byak wrote: > > > On 5/5/05, Richard Kowalczyk <richk@...805...> wrote: > > > > I will be glad to do anything else that anyone thinks will help explain > > > > the memory usage. > > > > > > Can you try loading these same files in turn (i.e. closing the > > > previous one when loading the next) into Inkscape instead of Inkview > > > and see if there is a noticeable difference? > > > > > -- > > Richard Kowalczyk <richk@...805...> > > > > > > > > -- Richard Kowalczyk <richk@...805...>

1 0

Re: [Inkscape-user] eps error (bad encoding)
by bulia byak 07 May '05

07 May '05

On 5/2/05, Aewyn <aewyn@...326...> wrote: > I just try to print from inkscape; as I know the only way to > produce a reasonable sized document is save as .eps > > Is is ok, but all my accent characters (őúéáűó) goes to its > unicode formats, so the result is totally unusable. Convert text to path - this is perhaps the most reliable solution. Other than that, I don't know what encoding the text in PS is supposed to be. I doubt it's Unicode. Latin-1? What about non-Western-European languages? Can any experts comment? -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 2

listener fixes
by MenTaLguY 07 May '05

07 May '05

Ok ... I think I fixed all the bugs in CompositeNodeObserver, so I've comitted my patch. I've not gone through and verified that it fixes all the layer etc. bugs yet, but if it doesn't it should at least make the remaining work of fixing them much easier. The commit ensures that two of my "five invariants" are now observed: * a listener should not receive events that occurred before its registration * a listener should not receive any events at all once it is deregistered Hmm, and actually also that "fifth and a half" invariant: it should be safe for a listener to unregister itself. The patch also had the effect of disabling the 'is_interactive' flag for attribute changes. However, the work I'd done since it had been introduced made a (much cleaner!) replacement very easy. [ I've not actually entirely purged the is_interactive flag yet, since that will require changing a lot of files, but I will do so once we're satisfied that these changes are working out. ] I've been testing most of the night, but please test yourself and see if you turn up anything. I'm still worried that some code somewhere was written that inadvertantly depended on a violation of the first invariant above. -mental

1 0

Extensions Update?
by unknown＠example.com 07 May '05

07 May '05

I just thought I would check in and see if there is anything new going on in the extension realm. (Ted, have you found any time to start working on the interpreter property and absolute paths?) I have recently created an effect that draws microtonal and multiscale stringed instrument fretboards. Sounds very useful doesn't it :) I have also started working on an effect to do isometric path extrusions. I think may have taken this idea as far as I am able. Anyone is welcome to pick it up and improve it if they wish. Besides Multiline text boxes, here are a few other extension autogui widgets I would find useful. Any comments? - Enumerated choices (drop down list box) - File selector - Mutually exclusive parameter groups (tabs) like: <tabset> <tab> <param name="length"></param> </tab> <tab> <param name="firstlength"></param> <param name="lastlength"></param> </tab> </tabset> And lastly Inkscape crashes on startup if an *.inx file contains a string param with an empty default value like this: <param name="crasher" type="string"></param> Starting program: /usr/local/bin/inkscape [Thread debugging using libthread_db enabled] [New Thread -1223995264 (LWP 7496)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1223995264 (LWP 7496)] 0x0836725f in ParamString (this=0x85ba1e0, name=0x0, guitext=0x0, ext=0x0, xml=0x862480c) at repr.h:175 175 repr.h: No such file or directory. in repr.h (gdb) bt #0 0x0836725f in ParamString (this=0x85ba1e0, name=0x0, guitext=0x0, ext=0x0, xml=0x862480c) at repr.h:175 #1 0x08366b30 in Inkscape::Extension::Parameter::make (in_repr=0x862480c, in_ext=0x85ba070) at extension/parameter.cpp:238 #2 0x083627d4 in Extension (this=0x85ba070, in_repr=0x0, in_imp=0x85a722e) at extension/extension.cpp:92 #3 0x0836c66b in Effect (this=0x85ba070, in_repr=0x0, in_imp=0x0) at extension/effect.cpp:26 #4 0x0836a258 in build_from_reprdoc (doc=0x84a859c, in_imp=0x0) at extension/system.cpp:418 #5 0x0836a3f0 in Inkscape::Extension::build_from_file ( filename=0x859f980 "/home/aaron/.inkscape/extensions/ffss.inx") at extension/system.cpp:447 #6 0x08365d22 in build_module_from_dir (dirname=0x85a86e0 "/home/aaron/.inkscape/extensions") at extension/init.cpp:207 #7 0x08365b81 in Inkscape::Extension::init () at stl_vector.h:501 #8 0x08122acc in inkscape_application_init (argv0=0x0, use_gui=0) at inkscape.cpp:580 #9 0x08117b6a in sp_main_gui (argc=1, argv=0xbffff9c4) at main.cpp:517 #10 0x081ec4fb in Inkscape::NSApplication::Application::run (this=0x0) at application/application.cpp:132 #11 0x08117703 in main (argc=1, argv=0xbffff9c4) at main.cpp:414 Aaron Spike

1 0

Re: [Inkscape-devel] Memory Problems
by Richard Kowalczyk 06 May '05

06 May '05

I tried doing what you suggested. I went though 26 slides, since it seemed to be enough to get an indication of the behavior. (Just to clarify - I opened the next one (from within the current one), then closed the current one - if I had closed the current one first, the memory would be cleared) The memory used seems to be roughly equivalent between inkscape and inkview, although inkview does use less. Either way though, the memory keeps going up as I go through more slides. I attached three files to this email - the result of doing the command: ps aux | grep -e "inkview" >> memory.txt; free -m >> memory.txt for three cases: memory_inkview.txt: after I clicked the right arrow to advance each slide, I ran the command. memory_one_per_time.txt: I did what you suggested, and opened each file in inkscape, then closed the old one, running the command for each new file. memory_all_open.txt: I opened each file in inkscape, but didn't close the previous file, so by the end, I had 26 files open at once. I ran the command after each file was opened. Thanks for your help, Rich. On Thu, 2005-05-05 at 19:38 -0300, bulia byak wrote: > On 5/5/05, Richard Kowalczyk <richk@...805...> wrote: > > I will be glad to do anything else that anyone thinks will help explain > > the memory usage. > > Can you try loading these same files in turn (i.e. closing the > previous one when loading the next) into Inkscape instead of Inkview > and see if there is a noticeable difference? > -- Richard Kowalczyk <richk@...805...>

1 0

new debugging aid
by MenTaLguY 05 May '05

05 May '05

I've introduced a logging facility; the goodies are in the Inkscape::Debug namespace. Set the INKSCAPE_DEBUG_LOG environment variable to a filename, and Inkscape will write a structured XML outline of its activities there. You can take advantage of this when debugging your own code. For example, if you want to highlight the changes that happen during a function, you add this to the top: Debug::EventTracker<Debug::SimpleEvent> tracker("my-func"); (if the function isn't inside the ::Inkscape namespace, you'll need to fully-qualify the type names) After you recompile, any (logged) events that happen during a call to your function will appear grouped under a <my-func> tag in the log. For example: <my-func> <set-attribute node="element(0x8956a218)=svg:g(#g123)" name="foo" value="bar"/> </my-func> (How it works: the <my-func> tag is written from the EventTracker's constructor, and </my-func> is written from its destructor when it goes out of scope.) If you want to log fancier stuff (e.g. taking advantage of attributes) you'll currently need to write your own subclass of Debug::Event and use that instead of Debug::SimpleEvent. Note that EventTracker will not create a Debug::Event object unless the log is turned on, so you don't pay a performance penalty when you're not using it. See src/xml/simple-node.cpp for some examples (which are sadly probably more complicated than they need to be). -mental

1 0