Performance issues when adjusting gradients in documents with high number of gradients
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
Triaged
|
Undecided
|
Unassigned |
Bug Description
While working on http://
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_
I removed the event handlers for the related situations and it increased performance dramatically with no ill effects (at least as far as I can tell). This change is included in the attached patch.
To reproduce, open this file with 600+ gradients
http://
Then using the gradient tool, move the gradient on the nearest penguin's bonnet or something and notice the latency.
Issue encountered on Arch Linux, in Inkscape 0.91-15 and trunk. The included patch is against trunk.
I was seeing something like 200-500ms latency on the following machines:
Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz (4-core, 24GB ram)
Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz (6-core, 32GB ram)
both Arch Linux (GNU/Linux 4.2.5-1-ARCH x86_64)
FailBit confirmed bug on
Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-63-generic x86_64)
tags: | added: gradient performance ui |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Hi, thank you for taking the time to report and propoe a patch for this issue !
I tested your patch and noticed a regression : when duplicating a gradient, the UI does not show the duplicated gradient (selecting another object triggers an update and shows it).
From what I saw your patch completely prevents redrawing the gradient UI when "modifying defs", I'm not sure if there are other cases where defs are modified when the fill&stroke tab is open that would be impacted (or if other components are affected, maybe auto palette/swatches but i did not test it)