puzzled. It doesn't look like a particularly severe leak if there is one. ~300MB virtual size shouldn't be forcing a machine with 1GB of RAM into swap.
When Ink is doing it's go-slow (+ blank form thing) I do not notice a slow-down in other apps. The only time the entire machine is non-responsive is when I close Inkscape after a go-slow. This is usually done by ctrl+alt+esc which gives me that little skull icon to clobber dead windows with. I also killall inkscape now and then. At that point the machine can "go away" for (I estimate) between 30 and 50 seconds. Serious lock-out.
If the problem is indeed Inkscape, the only thing I can think of would be something like massive spikes in memory consumption, where the memory was still quickly freed again, and therefore missed at the sample intervals we took.
I will take Eric's advice and try his script. I dunno if my forebrain is up to the whole graphing thing, but I'll do what I can :)
Since this behavior seems to be related to the general slowness-on-zoom issues, it may be that livarot's (our renderer's) tessellation code is exhibiting such behavior. That's a tenuous guess on my part right now though.
I must reiterate that the zooming is really quick - pretty much always.
I will try to explain the panning thing I see: 1. Start a fresh Ink - open a working file 2. Middle-button drag the canvas - there is a little flickering as it redraws, but five pixels (for example) mouse movement = five pixels of pan. 3. Time passes. Slowness sets in. 4. Middle-drag the canvas. Now 5 pixels of mouse movement = no panning at all. I have to drag the mouse across over half the screen before the canvas will pan only a small step (perhaps 50 or 100 pixels). So it's a lot of: a. Drag across screen. b. Let go - wait for a reallllly slow redraw with big black rectangles being filled by the drawing. c. Move mouse back across the screen. d. Goto a
So, I take to zooming with ctrl+mouse wheel in and out to move to new areas of a drawing. The zoom is damn quick. I don't understand it. When I get close to a dense area of the drawing (say fit-to-screen size) the slow redraw can get in the way, but I just wait it out. It's much much much better than panning.
So, the problems that Ink is throwing my way are: 1. Slowdown in "response" - most noticed when panning. But also in: a. The speed of the populating of dialogues like the fill/stroke dialogue. b. Selecting and deselecting gets very slow too. Sometimes select will not work at all and I must zoom out some before it will "see" what I am clicking. c. Very large slowdown when snapping to grid or paths. 2. Dialogues that malfunction - no fonts appear or no controls appear. 3. An eventual freeze and a forced app kill. * * I mostly notice the freeze when exporting to png. It will come up with a "cannot export this file" (I will try get the exact message) which is bogus because I have been doing it before. I think a form comes up that is asking me if I want to over-write an existing file or not but the controls are not visible and I cannot use "Enter" or "Esc" keys to control it.
/d