After updating to devlibs r46 moving objects around becomes too slow in my system and Inkscape is nearly unusable even for simple drawings. Open a new document, draw a rectangle and move it around: the lag is huge. Even changings of the cursor when hovering over it are updated with delays of 1 s or more. Moving and snapping guides (not to guides), on the other hand, is very fast. My system is a Pentium 4, 3,2 GHz, 2 Gb RAM with Windows XP SP3. Reverting to devlibs r45 (trunk 12277) gives back the previous (acceptable) response time. I know my system is old, but with r45 it's fine for all my needs. Isn't this terrible performance drop avoidable? Inkscape is already not a jaguar... Regards. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Hi Luca,
De : LucaDC <dicappello@...2144...> After updating to devlibs r46 moving objects around becomes too slow in my system and Inkscape is nearly unusable even for simple drawings. Open a new document, draw a rectangle and move it around: the lag is huge.
r46 is just a Cairo (1.11.2 to 1.12.14) and Pixman (0.22 to 0.28.2) libs update. I've tested it on four different computers with XP and Seven, and noticed no slowdown The bounding box seems to lag a bit behind the object, but I can't call it a huge lag.
Is anyone else also affected? To be sure it's no a local issue, would you be willing to test the version I've shared recently (ftp://download.tuxfamily.org/inkscape/inkscape-12262-cairo-1.12.14-experimental.7z)?
Regards, -- Nicolas
Hi Nicolas, I've tried your test version and got the same results as mine with r46. This morning I did a "bzr revert -r45" and "bzr update -r45" then a clean build and the slowdown has gone. Note that I didn't revert the trunk, only devlibs. It's not only a matter of bounding boxes: the dragged objects are drawn slowly too and it's not a matter of overloaded drawing because it happens in a clean file with only a rectangle and all snappings off. May this be something related to the hardware more than the OS? You tried on WXP and W7 but didn't specify on which hardware. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631p4966634.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 16-Apr-2013 03:58, LucaDC wrote:
After updating to devlibs r46 moving objects around becomes too slow in my system and Inkscape is nearly unusable even for simple drawings.
If you run Task Manager at the same time, is Inkscape using an unusual amount of CPU time? That may tell us if this is a "too much wait time" (low CPU usage) or a "too much looping/too short a wait time" (high CPU usage) issue.
Earlier versions of devlibs had problems with Inkscape burning up 15% or so CPU when just sitting idle.
https://bugs.launchpad.net/inkscape/+bug/871968
You might be seeing a more extreme variant.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
It's always around 16% - 17%, both with r45 and r46 but performances are way different between them.
-- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631p4966636.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 16-Apr-2013 09:03, LucaDC wrote:
It's always around 16% - 17%, both with r45 and r46 but performances are way different between them.
By always, you mean even when it is idle? If that is true this could be some variant of the 15% CPU problem.
Try the dll's linked here:
https://bugs.launchpad.net/inkscape/+bug/871968/comments/19
and see if it knocks the idle down to zero, and/or fixes the slow problem. (Of course, hang onto the original dll.)
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Yes, it is always around 16% when it's idle. But this is not the point: it has always been around that value. And with devlibs r45 it is too but the program is not slow. I've downloaded the two DLLs but I'll try them tomorrow as I have to update to r46 and do a clean build (which requires a bit bit of time). Regards. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631p4966638.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 16-4-2013 16:00, LucaDC wrote:
Hi Nicolas, I've tried your test version and got the same results as mine with r46. This morning I did a "bzr revert -r45" and "bzr update -r45" then a clean build and the slowdown has gone. Note that I didn't revert the trunk, only devlibs. It's not only a matter of bounding boxes: the dragged objects are drawn slowly too and it's not a matter of overloaded drawing because it happens in a clean file with only a rectangle and all snappings off. May this be something related to the hardware more than the OS? You tried on WXP and W7 but didn't specify on which hardware.
I know this is not the problem, but still want to ask: did you try switching the desktop color bit depth? Pre-r46 has crazy slow performance at 16-bit depth, who knows...
r46 works fine for me (perhaps relevant specs: i7, 16GB RAM, 64-bit win7 SP1, GTX 660 Ti). Nicolas's experimental build worked fine on my work laptop (i5, 4 GB RAM, 64-bit win7) and also on a colleague's PC (don't know exactly, but it's certainly a much older machine).
Cheers, Johan
Here the results with the DLLs. libglib-2.0-0.dll_has15cpu is the same as I usually have: 16-17% when idle, devlibs r45 fast, devlibs r46 slow. With libglib-2.0-0.dll_no15cpu the cpu usage goes to 0% when idle (why isn't this used in devlibs?) but the difference between r45 and r46 is still the same. Regards. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631p4966641.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
I've tried with 16 bit depth: with r45 I see no big differences but it's difficoult to say, with r46 things get surely worse. Maybe this helps in understanding what's going on. Regards. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631p4966642.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
I've just noticed the tweak tool is very slow, far slower than the select tool. Moving the tweak cursor, even with a blank new document maximized, can take up to half a second if the window is maximized.
~suv, do you have the same kind of issues when testing recent cairo versions on OSX? If not, I guess it's a win32 specific bug or a problem with the compiler or the configure options.
-- Nicolas
On 2013-04-18 15:08 +0100, Nicolas Dufour wrote:
I've just noticed the tweak tool is very slow, far slower than the select tool. Moving the tweak cursor, even with a blank new document maximized, can take up to half a second if the window is maximized.
~suv, do you have the same kind of issues when testing recent cairo versions on OSX? If not, I guess it's a win32 specific bug or a problem with the compiler or the configure options.
On OS X 10.7.5, I do not observe any dramatic performance regressions with the select tool or tweak tool, comparing trunk builds using - GTK+/Quartz 2.24.17. cairo 1.12.14, pixman 0.28.2 to builds using - GTK+/X11 2.24.13, cairo 1.12.2, pixman 0.26.2 beyond known somewhat slower screen updates/redrawing with Quartz-based builds (this does not depend on cairo version).
[*] Possible limitation of my observations: I can only test with small screen resolutions (built-in monitor of 13" MBP laptop, no external monitor available) - any slow-downs which possibly are related to window size are likely not reproducible with a max document window size of 1280 x 800 px (size of fullscreen mode).
On 18-Apr-2013 06:08, Nicolas Dufour wrote:
I've just noticed the tweak tool is very slow, far slower than the select tool. Moving the tweak cursor, even with a blank new document maximized, can take up to half a second if the window is maximized.
This may be hideously painful to do in practice, but since there is a gprof in mingw, in theory you could locate the section of code which is now slow. Maybe. Change the compile flag to use -pg -g -O0 and build fast and slow versions of Inkscape. Run them, and carry out exactly the same sets of operations in each. In between copy the gmon.out file to some other name, so a subsequent run does not overwrite it. Then analyze the gmon.out files with gprof. If you are really, really lucky, then some particular method will jump way up the 'time used' list, possibly even with line numbers.
Based on my own past results with gprof I estimate this method has about a 25% chance of showing something useful. If I had to guess the slow down is actually taking place in a library used by inkscape, and not in inkscape itself. That was the situation with the 15% CPU issue. gprof won't show anything useful about the contents of those libraries unless you rebuild them with -pg, which may be very hard to do. The method is unlikely to show you exactly where the issue is, because it is not good at measuring (huge iterations ) X (tiny times), but numbers one or two levels up, where this integrated time can be measured, may give you a clue where the problem is.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
I've just recompiled the pixman and cairo libs with a different compiler version in a cleaner environment. The test package is available at ftp://download.tuxfamily.org/inkscape/inkscape-12282-new-cairo.7z It has been tested on a i5 computer, virtualboxed Windows XP, and shows no slowness at all. Could you please give it a try?
Note that I doesn't notice the tweak tool issue on the same machine with the affected devlibs (yesterday's tests were on a slower machine -with a core2duo cpu- that I can't use today). -- Nicolas
I tried the package: apart from it being quite buggy (it crashes when I try to resize the non maximized window), the slowness is unchanged. But I noticed something maybe interesting: the delay in fullscreen (1280x1024) is the same but when demaximizing the window, the less big it is the less is the delay, same zoom, same dragged obect size (in screen pixels). This happens with trunk too. So it seems that the slowing overload is proportional to the size of the window to be redrawn.
-- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631p4966695.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
De : LucaDC <dicappello@...2144...>
I tried the package: apart from it being quite buggy (it crashes when I try to resize the non maximized window),
Yep, it crashes in Pixman, I can't say why.
I've replaced the test file with another one built with cairo-1.12.8. It doesn't crash, and isn't slow on my i5 computer. (ftp://download.tuxfamily.org/inkscape/inkscape-12282-cairo-1.12.8.7z).
Regards, -- Nicolas
No more crashes, same slowdown. I confirm that the entity of slowdown is directly proportional to the canvas area: small window = no slowdown, big window = big slowdown. It's not related to the zoom level or, to some extent, to the number of dragged objects. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631p4966722.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Hi Luca,
I'm still investigating the issue, and just found out that the computers I used to reproduced the bug were all using an Intel GPU. Tests with an nvidia GeForce 210 (GT218) show no slowness at all. Could you please tell me what kind of graphic card you have on your computer?
BTW, I've added a report on the freedesktop bug tracker: https://bugs.freedesktop.org/show_bug.cgi?id=71833 (Cairo 1.12+ very slow on Windows).
Regards, -- Nicolas
Hi,
Le Jeudi 21 novembre 2013 9h09, Nicolas Dufour <nicoduf@...48...> a écrit : I'm still investigating the issue, and just found out that the computers I used to reproduced the bug were all using an Intel GPU. Tests with an nvidia GeForce 210 (GT218) show no slowness at all.
Could some Windows users help me? I'd like to confirm the slowness only affects Intel graphics cards. Could you test a modified Inkscape binary (from ftp://download.tuxfamily.org/inkscape/inkscape-12282-cairo-1.12.8.7z), give your graphic card model and tell me if it's slow or not? IMHO it could be a blocker for 0.49 on Windows.
Thanks!
BTW, I've added a report on the freedesktop bug tracker: https://bugs.freedesktop.org/show_bug.cgi?id=71833 (Cairo 1.12+ very slow on Windows).
Regards, -- Nicolas
Hi Nicolas, unfortunately I cannot help you. The graphic card I'm using on my PC at work is an Intel 82945G Express Chipset Family so I can only confirm that my Intel graphic card exhibits the slowdown, not that other vendors' don't. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tp4966631p4969062.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 19-12-2013 13:31, Nicolas Dufour wrote:
Hi,
Le Jeudi 21 novembre 2013 9h09, Nicolas Dufour <nicoduf@...48...> a écrit : I'm still investigating the issue, and just found out that the computers I used to reproduced the bug were all using an Intel GPU. Tests with an nvidia GeForce 210 (GT218) show no slowness at all.
Could some Windows users help me? I'd like to confirm the slowness only affects Intel graphics cards. Could you test a modified Inkscape binary (from ftp://download.tuxfamily.org/inkscape/inkscape-12282-cairo-1.12.8.7z), give your graphic card model and tell me if it's slow or not? IMHO it could be a blocker for 0.49 on Windows.
NVIDIA GeForce GTX 660 Ti --> runs fine Switching to integrated Intel HD 3000 --> runs fine too
Do you have a particular "heavy" task that obviously runs too slow? I don't really know what to test...
Cheers, Johan
Le Jeudi 19 décembre 2013 21h09, Johan Engelen <jbc.engelen@...2592...> a écrit :
NVIDIA GeForce GTX 660 Ti --> runs fine Switching to integrated Intel HD 3000 --> runs fine too
Do you have a particular "heavy" task that obviously runs too slow?
Yes. It is particularly noticeable when moving a shape quickly (the bbox is lagging behind) or when moving the cursor with the tweak tool activated.
Thanks for your help! -- Nicolas
On 19-12-2013 22:03, Nicolas Dufour wrote:
Le Jeudi 19 décembre 2013 21h09, Johan Engelen <jbc.engelen@...2592...> a écrit : NVIDIA GeForce GTX 660 Ti --> runs fine Switching to integrated Intel HD 3000 --> runs fine too
Do you have a particular "heavy" task that obviously runs too slow?
Yes. It is particularly noticeable when moving a shape quickly (the bbox is lagging behind) or when moving the cursor with the tweak tool activated.
Well... trunk is actually much slower for me at the moment (a ton of warnings: ** (inkscape.exe:7240): WARNING **: Invalid state when picking: STATE_BBOX = 0, STATE_PICK = 4 )
If I move a shape quickly, the bbox is no longer updated (have to keep moving it pretty rapidly). I see the same for 0.48.x and trunk. The shape itself is nicely updated in 0.48.x and your binary. In trunk, the shape itself is not rendered nicely at all for quick movements.
thanks, Johan
participants (5)
-
Johan Engelen -
LucaDC -
mathog -
Nicolas Dufour -
~suv