Krita slowing down as time passes (after upgrading to 4.4.5)

Hi all, I upgraded to 4.4.5 a couple of days ago and noticed Krita got slower as time passed, even when I let the computer idle. I noticed it first with selection : I was selecting and moving parts of a layer, and Krita wouldn’t deselect (ctrl+shift+A). I hit the shortcut several times in a row, and after a while (about twenty seconds), a dialog with a progress bar popped up : “Waiting for image operation to complete : Deselect” and it did deselect, after four full minutes (I timed it). During this, the interface was still responsive, menus would open, etc. but I wasn’t allowed to interact with the canvas in any way. I suppose that dialog is blocking.

Restarting Krita completely fixes the issue. What info can I provide to help resolve this ?
I’m on Windows10, I work on pretty big images but I don’t think that’s the issue because it never did this before, even on similarly-sized images (~7k*4k).

I’ve been using Krita daily for six months now, as my job now involves a lot of illustration, and I don’t recall having this happen before. I think it started after my upgrade to 4.4.5. I’m going to confirm this in a bit by downgrading… by the way, where can I find the next-to-last version ?

Any idea what could be going on ?

Cheers,

Hadrien

EDIT I just found 4.4.3 in the news section (Krita 4.4.3 Released | Krita), installed it, and… it’s still happening, but only half the time ? It’s weird. I’m not sure where to search for a solution. Could it come from another program ? I don’t usually have many programs running : only XNView and SumatraPDF for viewing references.
The computer is an old-ish i7 5820k with 32GiB of memory and a 4GiB GeForce GTX970. The Windows install is very recent (less than one year) and hardly bloated at all, I use it for work only. The storage is an NVMe SSD.

Do you get orange or red memory bar (on the bottom bar of Krita) with a little /!\ symbol? If not, can you please check the task manager to see if the RAM seems to be used up?

It would be also helpful if you could check 4.4.0, then 4.3.0, then 4.2.9 to find a version where it wasn’t happening at all…

I also have an old 2014 CPU and I too work on images with size such as 3000x3000 and have encountered slowdowns in painting to the point that I am considering using GIMP for daily work. You can check here in the video below.

you can see the title bar flickering too there is some periodic thing that krita does at start of each brush stroke. Also, this is not just limited to brush stroke it happens with layer stack scroll or when zooming the canvas.

I also encounter slowdowns even while hiding and unhiding layers or deleting layers, A dialog
box pops up saying “removing nodes” etc. even grouping layer takes time.


And this happens every time, and it becomes annoying after a while.

Sometimes Krita crashes outright, yesterday it crashed 20 times while working. I am trying to find the way to trigger it, but I don’t know how to find the cause. I also notice vector layer operations use only one core of CPU for many tasks I only see one cpu core out of 8 spiking, may be all operations are not using other cores. It is just a guess.

We need to research more about this and report it. I will prepare a test file soon. If you happen to have a big file that you can share for testing please do.

I do get greenish yellow colour, I have 32 GB of ram and the memory indicator says it is using 4 GB so it is not at critical level too. I have seen that if you have multiple filter masks and transform masks with some vector layers in particular krita find it hard to refresh or catchup to our operations. Since most people don’t work on 3k sized image I didn’t find anyone complaining about this, but sooner or later when more and more people will be painting in 4k we will hear such reports.

1 Like

More possible findings and suggestions.

  • I noticed that by default the allocated memory is 50% in krita settings. Is it the same for everyone? I increase this to 75%, but then it would be great to have it at 75% by default or any other value the community agrees upon. Since both who have less ram and high ram would be in loss with 50% value I suggest increasing this.

  • Some type of layers don’t utilize all core for example vector layers. Some type of layer cause slow down like the transform masks. Layer refresh and operations are affected by these.

  • The memory bar or some other thing locks UI. I am guessing it is memory status bar it may be other thing. If you open multiple big images of similar size and work on something you notice your brush stroke or UI getting locked for half a second like shown in the video uploaded above.

I have prepared a quick and dirty demo file to play with. These files are not that big, but are somewhat similar to files that I work with. Lots of layers groups and lots of transform masks vector layers etc. If you have some other type of file that you work on daily basis and which makes krita slow down please provide it for testing. The file should be representative of the files you use daily. Open it in your machine and test it. The files are here on my nextcloud - Nextcloud

  • Check hiding unhiding layers,
  • check adding groups
  • check adding vector layers
  • Open demo and demo_001 file simultaneously and work on one if them
  • Add a shortcut to flaten layer (ctrl alt E) and then repeatedly flatten layers with transform masks

The results may vary depending on the specification of your machine please also note the specs in reply. Also, the amount of memory you have allocated in the settings.

Some workaround I am doing at my end to mitigate the issue. Although these are troublesome too because they increase time required to finish the project.

  • Breaking down the file in multiple files. Then grouping then in GIMP later in final stage.
  • Not using transform masks and vector layers or flattening them.
  • working on 75% file size and then scaling up later.
  • Not using layer FX or flattening it

Thanks for the help guys ! Memory usage is set to the default 50% in my preferences, so that’s around 16GiB. Here is my file : 311.44 MB file on MEGA

@tiar yes ! I never paid attention to that. Now that I reverted to 4.4.3, the memory bar is back to yellowish green :
capture_krita_memory
I’m going to test with portable Krita 4.4.5 now, hold on.
Also, I think 4.4.3 behaves normally… it may have had a stutter or two and I overinterpreted that as a symptom of the same problem… but really I’ve been leaving it open and working normally for an hour now and it’s smooth as it used to be. It really does seem to be down to the version used. Let me confirm that in a few minutes.

@raghukamath it’s nice to see I’m not alone in this boat !
As you can see there are only paint layers… I tend to group layers a lot, maybe this has an impact ? I just checked, and the deepest layer is nested under three groups. I am not using transform masks at all because they are buggy (they don’t behave correctly), and I seldom need the non-destructiveness they offer anyway. I will find the time to report this properly one of these days.

One of your suggestions was a game changer : I disabled the “drop shadow” layer style from the symbols at the top (the only layer styles in the entire file), and it made moving layers (with the move tool) about three or four times faster…! I guess Krita naively composites the entire image along with the layer styles at every tick. The improvement is drastic ! thank you.

I am downloading your file and will test with multiple Krita versions.

Yes this is also true with filter layers / masks, I have noticed that a slight move of any other part of the image even which is not under the filter refreshes whole canvas thus slowing thing down.

pinging @dkazakov too just to keep informed about this thread.

Hi @raghukamath - I tried it and had 2 crashes in 2 sessions so far. That’s the first times that 4.4.5 crashed on me…

One strange thing I noticed: after adding some layers, merging them down and undoing the merge (I then waited until CPU was down again), CPU constantly was going up and down at a cycle of a few seconds: 1st session between 0% and 20%, 2nd session 10-35% - with varying activity on multiple cores.

This “waving” didn’t settle again. After some time waiting, I tried moving a group (1st session) and Krita crashed. 2nd session I tried to add a shape on a vector layer and Krita crashed.

Before the crash, hiding/unhiding layers or groups was between instantly and a couple of seconds - nothing out of the ordinary I’d say. Adding vector layers seemed OK to me too. I’ll let it sit with both files open for a while now and try again later (without using undo).

My specs: Intel Xeon E3-1231V3 - 16GB RAM - GT730 - Win7-64

So… I didn’t get any more crashes. Also, I didn’t experience a slowdown over time - but: moving any node in these files has been painfully slow right from the start. Not in terms of the UI though, dragging went fast and without stutters. But after the action was done, CPU went fairly high for over a minute - even when moving was done only in the neighbourhood of hidden groups/layers.

I could definitely see activity on transform mask way down the layer stack. Even when those were within a hidden group. Hiding the layers with transform mask themselves though, I couldn’t see this.

The CPU-fluctuations (“waving”) I described, seems to happen only when undoing merge (vector layer + transform mask). Curiously it goes away after a new merge operation.

Hiding/unhiding groups/layers and adding groups/layers didn’t yield any problems here, performance was what I’d expect with FX and filter masks involved.

Hope this helps a little bit.

Hi, @Hadriscus and @dreamkeeper!

Could you please check this package: krita-4.4.7-alpha-ce13b40-x86_64.appimage — Яндекс.Диск

Does it fix your “Krita gradually becomes slower” problem?

In this package I disabled memory consumption estimation algorithms, which caused the bug reported by @raghukamath. So I wonder they were also a cause for your problem.

PS:

In this package most of the memory stats will be null, that is expected.

Hi @dkazakov - ‘appimage’ means it’s Linux, right? I’m on Windows, and it seems that @Hadriscus is as well. If you could provide a Windows version, I’ll happily test it.

Just to clarify: I didn’t experience any slowdown, just the other effects, I described above.

Sorry guys I haven’t been able to do much testing. I reverted to 4.4.3 and the issue is completely gone, so I’ll stick to that for the moment.

@dkazakov thanks for providing this build ! can I run it from Windows10 ? I found this step-by-step but I understand only 30% of the steps

Yes, you can do it like in the linked manual, but if you already say that you understand only a fraction of the manual, then you might be tempted to swear. Especially if you don’t like the command line very much.
The sentence “and possibly some other deps we consider part of each system”, should give you food for thought, I would interpret it to mean that the creator of this manual assumes you know what “other dependencies” are involved (if deps is to be translated as dependencies).
I hope I am not completely wrong with my assumption.
Edit: But if I’m wrong, please correct me!

Michelist

Thanks. To be honest, I haven’t looked very deep into it, but yes, I don’t understand what some of the steps even mean. This is probably aimed at people who have prior knowledge in whatever this is. I might have more time after my deadline which is on july 15th, I’ll give it a try then !

Hadrien

1 Like

Hi

Testing a test version of a linux appimage in windows is not really a good idea I think.
Especially if provided appimage if related to a performance problem…

It’s like trying a new cooking pan by putting it in a bigger pan rather than put the pan directly on the baking sheet :slight_smile:

Also, you might have some problem related to drivers, not sure how windows is able to inform linux subsystem about pen tablet position/pressure for example…

Grum999

2 Likes

(I would also count drivers as “dependencies”, but that is nitpicking).
But that it is possible in principle I find interesting.
But it would be better to set up a virtual machine there - you can then install the drivers, if there are Linux drivers for your tablet. I think Wacom tablets are all supported, or are there exceptions?
Edit: A VM is sufficient to observe the effect, but performance can only be achieved with powerful hardware.

Michelist

I began having delays and flickering when doing certain operation, like zooming, rotating the view and odd pen lag, mostly it just began today which is why I found myself in this forum. I was using version 4.4.2, so now I just loaded up version 4.3.0 and these problems have gone away.

These might not be the same issues ? Navigation hasn’t slowed down for me, image operations have (moving or renaming layers, painting, and so on)
Have you tried 4.4.5 ?

Not yet, I’ll give it a go.

Hi, @Hadriscus and @dreamkeeper

Here is a testing package for Windows. The name is confusing, sorry for that. The package is for 4.4.5, not for 5.0.

4 Likes

up :slight_smile:

Hi, @all!

I understand that most of the people in the thread are actually busy with the animation rendering bug, but could you please also check the package I linked above? This regression looks much more release-blocking than the animation one :slight_smile: