Created attachment 164441 [details] Copy of krita.log SUMMARY *** I have two large projects and the log I provided shows how large. In version 5.1.5 I believe it was able to open with no issues with the bi-linear scaling graphics setting. Now, I'm very lucky if it manages to open at all while scaling optimization is off. I think I'm probably overloading the visual processors, since the project I repeatedly tested has a lot of filter layers in it. In case this isn't a bug, my apologies in advance, but I'm just rather bummed that the older version had no trouble opening it and remaining stable the entire time. Something else I noticed is that the crashreporter file apparently does not recognize it as as crashes. The log, however, mentions that "krita did not close correctly". *** STEPS TO REPRODUCE 1. Open file with any scaling graphics setting. OBSERVED RESULT Krita closes either just after showing the canvas or just before. If lucky, it remained open, but after working with it for a while, something will likely be encounteredthat causes it to close after all (this is just an observation. Due to point two, I cannot reliably reproduce) EXPECTED RESULT It does not unexpectedly close at any point. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION I use a samsung galaxy Tab s7+
I found a workaround, but had not been able to pin down what settings caused the closing exactly and which prevented it until now. I call it a workaround, since I assume it is not the optimal way to use memory. Settings causing closing: - 5 or 10 GB Swapfile, not sure how much exactly, but relatively small. - RAM 90% allowed usage. Workaround settings: - First attempted to only increase swapfile (35GB) to no avail. - Then decided to REDUCE RAM usage limit, rather than increasing it. Ended up using 50%, but this value is arbitrary. Perhaps this helps to find some programmatic workaround/fix. Otherwise it may be useful to mention in the manual that reducing the RAM limit in combination with a larger swap file may improve performance in some situations. Everything, such as the krita status bar, suggests to INCREASE the RAM limit, because the swap file is being used. In my case, apparently, it is better to use the swap file, because otherwise krita closes. I still want to call it a crash, though, since it just stops and I have to restart it all the way. Anyway, having to choose between to evils, the swapfile is the lesser one.
Setting the ram limit lower is logical on Android, since it's the OS that decides to kill an app if it takes more than a certain amount of memory.
I see, that clears it up. Can you also tell me something about what that amount is? My Krita reports there is 5600MB available. And what would a good size of the swapfile be? Now that I think of it, what puzzles me is why this caused a problem in the transition between version 5.1.5 and 5.2.2. The OS was fine with it before apparently and then not anymore. Does the new version use significantly more RAM? If these questions are answered, I think this issue can be considered solved. However, it would be nice for the app to use lesser RAM if possible or a function that automatically adjusts the RAM limit, based on the total available RAM and the OS.
I'm not an expert when it comes to android, so I'm not sure about the limits. Krita 5.2.2 shouldn't use more memory for a given image, but rather, less, because we optimized a lot. On the other hand, there's a lot of new code, so Krita itself is bigger.
Hi, Corstiaan! I see that your image uses animation, could you also check one thing? What is your setting in Preferences->Performance->Animation Cache->Cache Storage Backend? If you switch to "On-disk", then your RAM consumption will be lower.
Does it? That's odd, since that was not my intention. If that's the case it only has one frame, so to speak. Is there a way to make sure an artwork is not saved/recognized as an animation? Still, I have checked your question and it is already on "On-disk". So no problem there. Honestly, having done what I described on 2024-13-3, the problem is reduced significantly. The status bar just permanently has a warning sign on it due to limited ram. I guess I just have to learn to draw smaller and limit my amount of layers at least a little.
I'm going to close this report now since there isn't much we can do about hardware limitations.