Hi Luca, 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-experi... Regards, -- Nicolas

On 16-4-2013 16:00, LucaDC wrote: 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

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 18-Apr-2013 06:08, Nicolas Dufour wrote: 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 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.

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, 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! Regards, -- Nicolas

On 19-12-2013 13:31, Nicolas Dufour wrote: 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

On 19-12-2013 22:03, Nicolas Dufour wrote: 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

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.

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.