slows to unusable when using swatches

Bug #734981 reported by shinyblue on 2011-03-14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Jon A. Cruz

Bug Description

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) on 2011-03-14
tags: added: color performance ui
su_v (suv-lp) wrote :

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

Changed in inkscape:
importance: Undecided → Medium
status: New → Confirmed
Changed in inkscape:
assignee: nobody → Jon A. Cruz (jon-joncruz)
ScislaC (scislac) wrote :
ScislaC (scislac) wrote :
Changed in inkscape:
status: Confirmed → In Progress
su_v (suv-lp) wrote :

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] <>

su_v (suv-lp) wrote :

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) wrote :

@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?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers