No, there is no need to worry about resources in the future (in fact, aside from some current bugs, Inkscape requires far less memory than before). As it's been known, Inkscape is currently going through a refactoring development cycle. What you pointed out is a known issue and as ~suv had linked, Krzysztof is aware if the problem. However, the current plan is for him to actually work on a critical bugfix we need in Pixman/Cairo before anything else directly in Inkscape. Please don't worry and be patient while things are being worked on (Krzysztof has a lot of the "heavy lifting" to do and he's also in school full time right now). Cheers, Josh On Fri, Oct 7, 2011 at 5:50 AM, LucaDC <dicappello@...2144...> wrote:

2011/10/8 Krzysztof Kosiński : Oh? I thought we ditched it entirely. Where else do we still use it? Alexandre Prokoudine http://libregraphicsworld.org

Krzysztof Kosiński wrote: Thanks for all the replies/explanations. Ok, I'll positively wait for an improvement on this side. But maybe it's worth saying that I always use geometrical bounding boxes, so I can't understand why all these useless calculations on strokes are performed anyway (if I correctly understand). Also, I've never experienced such problems so they must have been introduced by some recent modification: could you point it out so, for now, I can revert to just before it? Regards. Luca -- View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p32623348.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

~suv-2 wrote: Ok, thanks. I hoped not to have to go so much backward but indeed rev 10588 works as expected. Unfortunately, I'll have some difficulties in checking and appreciating Diederik's progresses (I've read "3) groundwork for tangential/perpendicular snapping" in rev 10672 comment :) Krzysztof Kosiński wrote: Does this mean that there's still a lot of work left before seeing a correct management of visual/geometric bounding box? If so, why not still keeping the quick "approximate" bounding box (at least for now) that worked so well instead of forcing the use of the much heavier visual one in all those cases where it's not really needed? Implementations would still remain wrong until they are corrected to use the geometric one. If I correctly understood the problem, of course. What I surely didn't understand is why the overload rises with the number of objects present in the drawing: if I have a lot of rectangles, moving a single one is a pain while it's not when I have only a couple. I can't catch the relationship with the complexity of bounding box calculation (and, anyway, we are speaking of rectangles...). Regards. Luca -- View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p32636800.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On Nov 9, 2011, at 3:22 AM, Krzysztof Kosiński wrote: Thanks for the info. Do you think it might be good to start a bit of a page on the wiki going to keep short notes on these? We might be able to get some support for helping you hunt these down if we can get some help going. Thanks.

On 2011-12-29 0:38, Alvin Penner wrote: This is tricky, as we do not only need to take endpoints into account, but also corners of paths. I am a little surprised by your report that apparently calculating the bounding box takes an amount of time that depends on the stroke width. Or did I misunderstand your report?

The purpose of the Path::Coalesce(double tresh) routine appears to be to detect whether successive segments on a multi-segmented path are smooth continuations of each other, and to merge them in that case. To do this a numerical tolerance is used to determine what is 'smooth', and the tolerance is based on the stroke width in this particular case. One can increase the likelihood of detecting a smooth join by increasing the stroke width, which is why the execution time depends (quite strongly) on stroke width. However, when calculating a bbox, there does not appear to be any practical reason for using this routine. The bbox will clearly not be affected by the merge of two segments if they are smooth, and the only obvious benefit is faster execution speed, which in this case has not been achieved. If I comment out the call to Path::Coalesce in line 784 of splivarot.cpp, then the execution speed returns back to a value that is comparable to Inkscape 0.48.2 as far as I can tell, while the bbox is unaffected by this change. The visual bbox obtained in this way contains more information than the bbox in Inkscape 0.48.2, since it responds to changes in endcap style and join style. Any objections if I comment out this line of code? -- View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p33063833.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On 2-1-2012 1:00, Alvin Penner wrote: Yes. The item_outline function is not only used for bbox calculations. It is also used when converting 'object to path'. Please make a 'separate' path outline function for the bbox calculation. Could be as simple as Geom::PathVector* item_outline(SPItem const *item, bool coalesce = false) Thanks a bunch for looking into the performance issues, Johan

On Jan 2, 2012, at 3:08 PM, Krzysztof Kosiński wrote: Sometimes it's good to have an optional parameter, but then again sometimes it helps to have a separate function with an explicitly different name (even if at the implementation they end up calling a shared common function with a parameter). Personally I think it really comes down to which one will make the code that uses these easier to read. And I do dislike the name "item_outline()" as it seems somewhat vague. A name more like "createOutline()" or "createOutlineFrom()" might be a fair replacement. Hmmm... and if one took "createOutline()" as a name, then a choice to provide two functions might end up with "createOutline()" and then a second method named something like "createOutlineCoalesced()" or "createCoalescedOutline()" could be chosen. So Krzysztof, given all of that, do you think this is a case where Geom::PathVector *newThing = item_outline_coalesced(myItem); is best or is it one where we'd want Geom::PathVector *newThing = item_outline(myItem, true); for getting the best code legibility? Oh, and there is always the consideration of not using plain data types for flags, but having an explicit enum instead. That variation would give us Geom::PathVector *newThing = item_outline(myItem, COALESCE);

On 04/01/2012 03:06, alvinpenner wrote: Initial tests with debug and optimized builds (both X11 and Quartz based) on two systems - Mac OS X 10.5.8, 32bit, 2.4 GHz Intel Core 2 Duo, 4GB RAM (upgraded) - OS X 10.7.2, 64bit, 2.4 GHz Intel Core i5, 8GB RAM show greatly improved performance when editing files with moderately complex stroked paths ('share/examples/l-systems.svgz' it a good test file IMHO: compare moving one of the generated paths - by dragging it with the mouse - in r10834 and r10835). Debug builds (-g -O0) still noticeably lag compared to optimized builds (-O3), and the difference of performance between the two laptops (32bit vs 64bit ?) is quite big. But overall trunk is now much closer to the performance of current stable (if using an optimized build). Many thanks @all for addressing this (r10835)! I do want to ask about another (possibly related) performance issue which has been bothering me in trunk builds for quite some time and is still present in r10835 (note: performance of the same operations in stable 0.48.2 is ok and fast compared to trunk). --> Spike of memory usage when zooming in closely in a plain document with lots of dashed stroked lines (e.g. a floor plan) (no filter effects, patterns, markers, etc. involved) Please download the SVG file from <http://commons.wikimedia.org/wiki/File:Zitouna_Mosque_plan.svg> 1) open it in current trunk build of inkscape 2) enlarge the document window 3) zoom in repeatedly (to get below 100%) At some point after changing the zoom levels a lot, Inkscape's memory usage explodes and it grabs whatever it can get (causes paging even with 8GB RAM), and it takes a long time until the window finally gets updated. The memory (> 2.6 GB) is released immediately when opening a new window and closing the one with the mosque plan zoomed in (i.e. keeping the same inkscape process running, with a new, empty document). I have this drastic performance loss when zooming in with such a sample file even when using optimized 64bit builds and 8GB RAM - on my older 32bit system, Inkscape usually stops responding, and I have to force-quit it (happens even after upgrading RAM from 2GB to 4GB). If I edit the file and modify all objects (remove strokes or convert them to path, add fill as needed for tests), performance with zoom operations is ok -> this makes me think it is related to what is discussed in this thread. Possibly due to the many _dashed_ stroked lines? Can anyone on linux/windows reproduce this? ~suv

2012/1/4 Nicolas Dufour <nicoduf@...48...>: Does it still happen if you set the environment variable _INKSCAPE_DISABLE_CACHE to 1? e.g. in command prompt: set _INKSCAPE_DISABLE_CACHE=1 inkscape Regards, Krzysztof

Confirmed on Windows XP. -- Nicolas

On 4-1-2012 3:06, alvinpenner wrote: How about backporting this to 0.48.x to increase its speed? Do we dare do it? ;) Ciao, Johan

On 25/01/2012 18:05, ~suv wrote: Steps to reproduce a similar loss of performance with basic Inkscape shapes: 1) delete/rename preferences file 2) launch inkscape (trunk) 3) draw three stars (use default settings, but increase number of corners to 200) 4) draw a rectangle Test 1: 5) drag the rectangle with the mouse -> slight delay, depending on general system performance, but noticeably delayed compared to Inkscape 0.48.2 Test 2: 6) select the three stars, and change the stroke style to 'Round Join' and 'Round Cap' 7) drag the rectangle with the mouse -> noticeably (IMHO huge) loss of performance while dragging a simple shape Note: the 'Spirograph' path in the second test file of the bug report doesn't even use rounded joins and caps. hth, ~suv <https://bugs.launchpad.net/inkscape/+bug/906952/+attachment/2692739/+file... <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10835>

On 29-12-2011 0:38, Alvin Penner wrote: Keep in mind that there are cases where we really do not need to know the bbox very accurately, so it would be good to bring the approx bbox calculation back. Ciao, Johan

On 10/10/2011 02:21 PM, LucaDC wrote: What I believe that has happened is that someone introduced the geometric bounding box vs. visual bounding box option at some point in time, for a specific purpose. E.g. for allowing the user to specify dimensions of the geometric bounding box, whereas before Inkscape only had the visual bounding box. That's likely why it's a sub-option for the selector tool, and not a general option. Then, over time, more and more code was implemented that reads that parameter for other purposes, up to the point where we are now: some codes uses the visual vs. geom. bounding box parameter, whereas other code simply always uses the visual bounding box. That's probably related to what you're seeing and not what you weren't expecting. Diederik