| 2015-12-30 19:27:26 |
Mark Riedesel |
bug |
|
|
added bug |
| 2015-12-30 19:27:26 |
Mark Riedesel |
attachment added |
|
0001-Remove-unncessary-gradient-event-handlers.patch https://bugs.launchpad.net/bugs/1530198/+attachment/4542343/+files/0001-Remove-unncessary-gradient-event-handlers.patch |
|
| 2015-12-30 19:28:36 |
su_v |
tags |
|
gradient performance ui |
|
| 2015-12-30 19:30:08 |
Mark Riedesel |
attachment added |
|
Example SVG with a ton of gradients https://bugs.launchpad.net/inkscape/+bug/1530198/+attachment/4542344/+files/ChristmasTux2015.svg |
|
| 2015-12-30 19:35:44 |
Mark Riedesel |
description |
While working on http://klowner.com/wallpaper/christmas_tux_2015 I encountered a very irritating performance issue when attempting to adjust gradients. The issue became progressively worse as I neared completion of the document.
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_to_pixbuf, from there I determined that the gradient thumbnail lists on both the Tool Controls Bar as well as the Fill and Stroke were clearing their entire list of gradients and rebuilding them on each mouse drag event while adjusting gradients on shapes.
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).
To reproduce, open this file with 600+ gradients
http://klowner.com/wallery/christmas_tux_2015/download/ChristmasTux2015.svg
Then using the gradient tool, move the gradient on the nearest penguin's bonnet or something and notice the latency. |
While working on http://klowner.com/wallpaper/christmas_tux_2015 I encountered a very irritating performance issue when attempting to adjust gradients. The issue became progressively worse as I neared completion of the document.
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_to_pixbuf, from there I determined that the gradient thumbnail lists on both the Tool Controls Bar as well as the Fill and Stroke were clearing their entire list of gradients and rebuilding them on each mouse drag event while adjusting gradients on shapes.
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).
To reproduce, open this file with 600+ gradients
http://klowner.com/wallery/christmas_tux_2015/download/ChristmasTux2015.svg
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. |
|
| 2015-12-30 19:40:17 |
Mark Riedesel |
description |
While working on http://klowner.com/wallpaper/christmas_tux_2015 I encountered a very irritating performance issue when attempting to adjust gradients. The issue became progressively worse as I neared completion of the document.
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_to_pixbuf, from there I determined that the gradient thumbnail lists on both the Tool Controls Bar as well as the Fill and Stroke were clearing their entire list of gradients and rebuilding them on each mouse drag event while adjusting gradients on shapes.
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).
To reproduce, open this file with 600+ gradients
http://klowner.com/wallery/christmas_tux_2015/download/ChristmasTux2015.svg
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. |
While working on http://klowner.com/wallpaper/christmas_tux_2015 I encountered a very irritating performance issue when attempting to adjust gradients. The issue became progressively worse as I neared completion of the document.
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_to_pixbuf, from there I determined that the gradient thumbnail lists on both the Tool Controls Bar as well as the Fill and Stroke were clearing their entire list of gradients and rebuilding them on each mouse drag event while adjusting gradients on shapes.
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).
To reproduce, open this file with 600+ gradients
http://klowner.com/wallery/christmas_tux_2015/download/ChristmasTux2015.svg
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) |
|
| 2015-12-30 19:44:45 |
Mark Riedesel |
description |
While working on http://klowner.com/wallpaper/christmas_tux_2015 I encountered a very irritating performance issue when attempting to adjust gradients. The issue became progressively worse as I neared completion of the document.
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_to_pixbuf, from there I determined that the gradient thumbnail lists on both the Tool Controls Bar as well as the Fill and Stroke were clearing their entire list of gradients and rebuilding them on each mouse drag event while adjusting gradients on shapes.
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).
To reproduce, open this file with 600+ gradients
http://klowner.com/wallery/christmas_tux_2015/download/ChristmasTux2015.svg
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) |
While working on http://klowner.com/wallpaper/christmas_tux_2015 I encountered a very irritating performance issue when attempting to adjust gradients. The issue became progressively worse as I neared completion of the document.
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_to_pixbuf, from there I determined that the gradient thumbnail lists on both the Tool Controls Bar as well as the Fill and Stroke were clearing their entire list of gradients and rebuilding them on each mouse drag event while adjusting gradients on shapes.
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).
To reproduce, open this file with 600+ gradients
http://klowner.com/wallery/christmas_tux_2015/download/ChristmasTux2015.svg
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:
Arch Linux (GNU/Linux 4.2.5-1-ARCH x86_64)
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)
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) |
|
| 2015-12-30 19:45:53 |
Mark Riedesel |
description |
While working on http://klowner.com/wallpaper/christmas_tux_2015 I encountered a very irritating performance issue when attempting to adjust gradients. The issue became progressively worse as I neared completion of the document.
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_to_pixbuf, from there I determined that the gradient thumbnail lists on both the Tool Controls Bar as well as the Fill and Stroke were clearing their entire list of gradients and rebuilding them on each mouse drag event while adjusting gradients on shapes.
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).
To reproduce, open this file with 600+ gradients
http://klowner.com/wallery/christmas_tux_2015/download/ChristmasTux2015.svg
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:
Arch Linux (GNU/Linux 4.2.5-1-ARCH x86_64)
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)
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) |
While working on http://klowner.com/wallpaper/christmas_tux_2015 I encountered a very irritating performance issue when attempting to adjust gradients. The issue became progressively worse as I neared completion of the document.
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_to_pixbuf, from there I determined that the gradient thumbnail lists on both the Tool Controls Bar as well as the Fill and Stroke were clearing their entire list of gradients and rebuilding them on each mouse drag event while adjusting gradients on shapes.
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).
To reproduce, open this file with 600+ gradients
http://klowner.com/wallery/christmas_tux_2015/download/ChristmasTux2015.svg
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) |
|
| 2015-12-30 19:46:38 |
Mark Riedesel |
description |
While working on http://klowner.com/wallpaper/christmas_tux_2015 I encountered a very irritating performance issue when attempting to adjust gradients. The issue became progressively worse as I neared completion of the document.
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_to_pixbuf, from there I determined that the gradient thumbnail lists on both the Tool Controls Bar as well as the Fill and Stroke were clearing their entire list of gradients and rebuilding them on each mouse drag event while adjusting gradients on shapes.
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).
To reproduce, open this file with 600+ gradients
http://klowner.com/wallery/christmas_tux_2015/download/ChristmasTux2015.svg
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) |
While working on http://klowner.com/wallpaper/christmas_tux_2015 I encountered a very irritating performance issue when attempting to adjust gradients. The issue became progressively worse as I neared completion of the document.
I did some profiling with gperftools and it showed a ton of calls to sp_gradient_to_pixbuf, from there I determined that the gradient thumbnail lists on both the Tool Controls Bar as well as the Fill and Stroke were clearing their entire list of gradients and rebuilding them on each mouse drag event while adjusting gradients on shapes.
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://klowner.com/wallery/christmas_tux_2015/download/ChristmasTux2015.svg
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) |
|
| 2015-12-30 23:53:15 |
Mc |
inkscape: status |
New |
Confirmed |
|
| 2015-12-31 07:12:38 |
jazzynico |
inkscape: status |
Confirmed |
Triaged |
|
