slows to unusable when using swatches

[shinyblue]

e.g. move a handle on a simple (2 stop) gradient, in a simple rectangle, and wait a few seconds before it updates; often it will never catch up with the position of the mouse.

I've noticed that this happens a lot since I've started using swatches (great feature, in theory). I can filter out all osb: attributes (killing my swatch - and importantly, killing all defs not used in the file that vacuum defs leaves in there), then vacuum defs, then it functions descent speed.

Obviously referencing a definition instead of defining the colour in-place adds an overhead, but I would expect only a very slight one?

Is this helpful?

Inkscape reports itself as "0.48+devel r (Nov 21 2010)" although it's packaged as 0.49 for Ubuntu 10.10 amd64. It's running on a new i3 machine with 4Gb ram.

[su_v (suv-lp)]

reproduced with Inkscape 0.48+devel r10208 on OS X 10.5.8 (i386)

[su_v (suv-lp)]

In addition to the steps to reproduced as discussed on irc [1], here's a another test case indicating that the trigger is the 'Fill & Stroke' dialog itself, when opened for a file with existing custom swatches:

1) open attached document in Inkscape (default preferences)
2) switch to the gradient tool and move any gradient handle
   -> no lagging
3) switch back to the select tool
4) open the 'Fill & Stroke' dialog (docked)
5) switch to the gradient tool and move any gradient handle
   -> lagging starts immediately

In current trunk, for me this behavior persists in the current session even if the current document window has been closed and later reopened (via 'File > Open Recent'). In Inkscape 0.48.1, the noticeable lag after opening the Fill&Stroke dialog seems to be limited to the current document window, and does not affect later editing of the same file in a new window.

Tested with Inkscape 0.48.1 and 0.48+devel r10244 on OS X 10.5.8 (i386)

[1] <http://pastie.org/private/kg91ehmw4bnxklzso389w>

[su_v (suv-lp)]

Performance issue when dragging gradient handles also reproducible (as described in comment #4) if inkscape was built without optimization:
last tested with r10463 on Mac OS X 10.5.8 (i386), two separate builds using GCC 4.2.1 with '-g -O0' and '-g -O3'

[su_v (suv-lp)]

@Jon - the changes in revision 10244 ("Queue swatch updates during periods of high UI usage, such as dragging gradient handles. Fixes bug #734981.") apparently trigger a constant CPU activity of 15-20% on some Windows systems, even if Inkscape is completely idle (inactive and minimized).

In bug #871968 David Mathog points out a bug in the Windows port of Glib/glibmm, and proposes a workaround. Any chance you could review the issue and comment in bug #871968?