Changing layer orders (moving UP/DOWN) in Krita has always been very slow. On an i7-3520M machine, an A4 300dpi picture took me 5~10 seconds to move one step. And that was only the case of an 8 bits picture. With a 16 bits picture, it took me more than a minute to finish one step. During such a process, Krita becomes completely unresponsive, but the CPU is not fully utilized at first -- only 1 thread is being fully taken. After passing many seconds, it suddenly takes up all CPU resources for 1~3 seconds, then the process is finished. In comparison, Photoshop and GIMP can finish changing layer order in a blink with zero CPU usage. Changing layer orders is a quite frequently used function, can this be improved? Reproducible: Always
Hm... How many layers in total do you have? I guess my test images with a about a dozen layers isn't terribly realistic. Around mid-october we already fixed one reason for slowness -- but more improvement would be good, of course.
I encounter this kind of slowdowns on daily basis, but it was this particular file that snapped me last night: http://tysontan.com/temp/freesoftware/kde/mascot_20140731_konqui-app-system.kra (BTW, opening up this document is super slow, too. Is it normal for a 16 Bits picture?) The slowdowns do not happen to the very first step right after you open it up. However, if you continuously move a layer UP/DOWN for many steps in a short period of time, it gets worse on every step. For me, the slowdown starts from the 2nd step (~3 seconds). This also happens after you apply many brush strokes then immediately move a layer UP/DOWN (which is the action that took me 90 seconds to unfreeze Krita yesterday) When you feel the slowdown is adding up, you can stop for a few minutes , then Krita can do the next few moving UP/DOWNs faster. Is this related to memory/history management?
New findings: Deleting multiple layers in a short period of time also triggers slowdown, no matter how large the picture is, how much information the deleted layer holds. The slowdown/freeze effect also adds up on each deletion, very similar to the symptom of changing layer orders. Maybe all commands in the Layer docker are affected by the slowdown/freeze.
I have to say, moving layers is very slow and "Sticky" on my machine too, compared to other apps. Its actually faster to just use the up/down arrows in Krita. I experience lag when moving any layer into a group mostly. I click on a layer and drag it into a group, and i'm left wondering if it even registered, and 3 or so secs later it actually moves into the group. This is compared to when I use the "move into group" button, it happens quicker, but even then its not as fast as other apps, which do it instantaneously. I don't know how useful this information is for development in this area, but I can say it definitely enough to make the experience less enjoyable. (I'm on a win7 64bit OS, and have 32gb or ram, i7 processor.)
I had it as well while making the Azalea file. It's the primary annoyance for me with layers now. If you teach me how to profile we might be able to get more information.
Okay... This isn't something to try on slow or low-memory systems, though! On Linux, install: * valgrind * kcachegrind Then start Krita like this: valgrind --tool=callgrind --instr-atstart=no krita screencast_azaleas.kra callgrind is the profiling tool in valgrind (memcheck checks memory errors). We don't want to profile the startup, hence --instr-atstart=no. When krita has started and loaded screencast_azaleas.kra, enable profiling with: callgrind_control -i on It'll say: PID 3134: krita screencast_azaleas.kra sending command instrumentation on to pid 3134 OK. Now drag one layer into a group and wait... And wait, and wait. I'm already waiting an hour for the operation to complete :-) When it's done, do: callgrind_control -i off callgrind_control --dump Close krita. There'll be a file called something like callgrind.out.11298.1 Open that in kcachegrind and see what takes most cpu :-)
Created attachment 92507 [details] callgrind trace
I also checked with adding some tracing debug statements. The azalea image is a bit misleading because when I move one of the layers, all the clones want to register updates as well. If I take a normal image with a dozen layers and two groups, d&d'ing a layer into a group causes only one update, so that can't be the problem.
Hello and thank you for the assistance and help :) I have the same problem with layers. I feel that the bug is affecting to the CPU performance -not only the performance of Krita- and this is terrible. For example, if I change the order of layer when I'm calling by Skype, this program runs bad too. I hope you can put solution because I really love the program.
Bah, it's simple enough... Gimp and Photoshop don't recalculate the image every step, only after the user is done moving layers about for a bit. We try to recalc the stack after every mode, which causes a huge backlog of calculations. We need a kind of update timer here :-)
See patch: https://phabricator.kde.org/D263
This should be fixed in 3.0 :-)
Great news. Thanks! :)
Hello, I'm not familiar at all with bug tracking so cant really offer much help. But I'm still getting this behaviour in 3.0. Had to switch back to photoshop. Takes forever to arrange my layers, can never be sure if the layers will be in the order I try to have them because of unresponsiveness. Usually have to rearrange them after trying. RAM seems to be fine, not spiking or anything, processor seems to be working alot. I'm using windows 7 64bit on a lenovo think pad with i7 processor and yiynova tablet monitor, but will try this with my windows 10 surface pro aswell later. Would love to switch from photoshop to krita, as paintig and rulers are awesome on krita (when not lagging like crazy)
Not sure if this is allowed on this forum, but I found a comment regarding this with an animated gif showing exactly what I'm experiencing. (also not sure if this will become a link...) https://forum.kde.org/viewtopic.php?f=288&t=132872
We also got another report about this recently, but I cannot find the duplicate of course. The problem is that I cannot reproduce it: if I test with a document with a hundred or so layers, drag and drop is really responsive, as is using the up and down buttons. I'm testing on a 32gb windows 7, 32 gb linux, 4gb win10, 16gb osx system, and in virtual machines....
Hello, thanks for the fast reply! Ok, so this is somewhat rare occurence. I'll do some testing when I have more time with the surface pro 4 and also with my desktop to see if this happens with all of them. Too bad this laptop is currently my main work horse for drawing. Now that I think of it, the earlier version of Krita was actually a bit more faster with the layers on my laptop. But still sluggish enough not to get me to change programs. Also switching layers on and off is very slow.
What is your usual image size, color model, channel depth & number of layers?
Oh, and if you can share a test image with me that always shows the problem for you, I might be able to reproduce. You can mail me privately: boud@kde.org.
Hello Normally my work has around 100-300 layers (lots clipping masks etc.) in alot of nested groups with some simple layer effects for some groups (gradient fill etc). image size is around 6000x3000 to 10 000x5000 usually the starting point is multiples of 1920x1080. colours nothing fancy, RGB 8bit With Krita I didn't get more than a few layers and the lagging started. I'll email a file for you. It is the one I started working on but abandoned after the lag got too severe. It was just on initial sketching phase.
Updating a bit. Tried the file on surface pro 4. File worked fine, was compeletely workable. I think this surface is more powerfull than my laptop anyways so that might explain it. I then loaded the final psd I made with photoshop and it loaded as well. A bit slowly but eventually it did, wich is actually pretty awesome. That file however had one of those nested groups that recreated the problem. When moving single layers around everything is fine, but when trying to move that large nested group, krita goes unresponsive. Krita will unfreeze after I release the layers but I have no idea where it will end up in the layer stack. It feels like Krita is trying to select all individual layers at once rather than think the layer group as one single selection and move them around all the time while I'm deciding where to put them (yeah I don't understand the technicalities 8D)
Hm, the file you sent me worked fine for me, but it's smaller than what you describe above. It also doesn't take oodles of memory. I've got another report about a file that matches your description and that went from taking 3gb of memory to 13gb, so when Dmitry is back from his vacation and has finished the gif exporter, I'll ask him to take a look.
Hello! Yeah the file I sent you was a sketch image for the final psd. The sketch worked fine on surface, but the final psd didn't work smoothly anymore. I can't send that final psd to you as it's work related. I now had some time to play around with krita on the surface, and made an image that imitates what I usually do for work. with nested layers and some clipping masks. Painting and mostly all other normal functions work well but just moving the layers (especially the layer groups) around is a real pain and halts krita completely. I also have some other minor gripes with the layer system as well, but that might just be that I'm so used to photoshop. Saved to psd and tried the same file on photoshop and everything worked fast and smoothly. Only clipping groups didn't translate to photoshop. I'll send the file to you and hopefully it could be of some help.
*** This bug has been marked as a duplicate of bug 364037 ***
Git commit 7b1b729cf5643574ff049d13c624e8562fcd5770 by Dmitry Kazakov. Committed on 21/06/2016 at 12:00. Pushed by dkazakov into branch 'master'. Add two patches for the Windows version of Qt This effectively fixes the D&D stalls when Qt tried to request entire QImage every time Windows asks it about the list of supported mime types. Related: bug 364037 CC:Shawn.Rutledge@qt.io A +37 -0 3rdparty/ext_qt/0001-Don-t-request-the-MIME-image-every-time-Windows-asks.patch A +30 -0 3rdparty/ext_qt/0002-Hack-always-return-we-support-DIBV5.patch M +2 -0 3rdparty/ext_qt/CMakeLists.txt http://commits.kde.org/krita/7b1b729cf5643574ff049d13c624e8562fcd5770
Git commit 5f1238207cb73ffcc4082b336a1329c78a7bf47b by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 24/06/2016 at 06:08. Pushed by rempt into branch 'krita/3.0'. Add two patches for the Windows version of Qt This effectively fixes the D&D stalls when Qt tried to request entire QImage every time Windows asks it about the list of supported mime types. Related: bug 364037 CC:Shawn.Rutledge@qt.io A +37 -0 3rdparty/ext_qt/0001-Don-t-request-the-MIME-image-every-time-Windows-asks.patch A +30 -0 3rdparty/ext_qt/0002-Hack-always-return-we-support-DIBV5.patch M +2 -0 3rdparty/ext_qt/CMakeLists.txt http://commits.kde.org/krita/5f1238207cb73ffcc4082b336a1329c78a7bf47b