I often need to create large files (~9500x4500px) to print large artworks. With lots of layers Krita gets quickly slowly and then I get a memory problem. Every 15-20 minutes it freezes and the screen turns grey-black. I have to wait 3-5 minutes till I can continue with my work and this can be very distracting. It would be great to know what is going on. The grey-black screen doesn't give me any information. Maybe a box could answer these questions: How long do I have to wait? What is the problem and how can I fix it? I would like to avoid closing Krita if this problem occurs. Mostly because Krita doesn't restores all of my settings: Bug 363331 - Feature request: Krita restores settings after restart - https://bugs.kde.org/show_bug.cgi?id=363331 I hope the performance will improve in the future. Reproducible: Always Steps to Reproduce: 1.Not easy to reproduce ;). Paint a ~9500x4500px file with many details like this one http://sylviaritter.deviantart.com/art/Quantal-Quetzal-609390302. 2. 3.
Hi Silvia, Thanks for your bug reports! Unfortunately, Ubuntu 16.04 only comes with Krita 2.9.7, which is pretty old -- the 2.9 series is now at 2.9.11, and memory consumption is one of the things that got improved along the road, though Krita is still quite hungry for memory. We're now working towards the first release of Krita 3.0. Are you on a 32 or 64 bits version of Ubuntu?
Hello :). Thanks for the fast reply. I've updated Krita to 2.9.11 and i will let you know during the next six days if the memory consumption is still a huge problem. I'm on a 64 bits version of Ubuntu. I've also updated the other bug reports for 2.9.11.
Also, don't hesitate to test-drive the 3.0 builds -- they are appimages, so it's just a download, make executable and execute. No installation needed!
Setting to needinfo instead of unconfirmed.
Oh -- and if you encounter more problems, please add a screenshot of the performance page of the settings dialog & info about your pc's memory, cpu and gpu.
Created attachment 99115 [details] Krita Performance
Created attachment 99116 [details] PC Information
I will test-drive the 3.0 builds after I've finished my current painting. Thanks for the tips/help :). Yesterday I had some minor performance problems. Just started a painting with a few layers. I will let you know if it gets worse. I've also attached my pc's info and the performance page.
I finished a new large painting in 2.9.11 and I'm still having issues with full memory. Especially turning layers on and off and merging layers takes too long. Krita still freezes and the screen turns grey-black for 3-5 minutes. I restarted Krita, but it didn't take long until memory was full again. The Advanced Color Selector turned grey for a while and I blindly had to select the colors. Closing and opening it again didn't help. After a while the Advanced Color Selector turned back to normal. I must admit I'm a bit scared to test-drive the 3.0 builds. Usually I prefer stable builds.
Well, we'll be released 3.0 stable next week. One of the things that got a lot better compared to 2.9 is exactly turning layers on and off, merging layers and moving them around. Dmitry is still hunting for memory issues, though.
Oh, and if the color selected turns grey -- check that you don't have a grayscale layer in an rgb image. It will also turn gray if you select a mask, because masks are grayscale.
Okay, great, thanks. I'm looking forward to the 3.0 release next week. I will let you know if I still have problems with full memory in 3.0 end of next week. I'm quite sure that I didn't had a grayscale layer in my rgb image. But good to know, thanks :).
Confirming.
Git commit 54282a72cee6256f29be9970793b32f6ffae6aa1 by Dmitry Kazakov. Committed on 15/07/2016 at 10:01. Pushed by dkazakov into branch 'kazakov/memory-optimizations'. Implement data pool for the chunks in openGL canvas updates This patch implements KisTextureTileInfoPool. A special object that keeps track of all the chunks allocated during the openGL canvas updates. This class is also capable of tracking multiple openGL tile sizes and color space pixel sizes. It should fix the most of the memory fragmentation problems, especially on Windows. Related: bug 364848 M +0 -1 libs/ui/CMakeLists.txt M +8 -1 libs/ui/opengl/kis_opengl_image_textures.cpp M +4 -0 libs/ui/opengl/kis_opengl_image_textures.h A +156 -0 libs/ui/opengl/kis_texture_tile_info_pool.h [License: GPL (v2+)] D +0 -22 libs/ui/opengl/kis_texture_tile_update_info.cpp M +58 -72 libs/ui/opengl/kis_texture_tile_update_info.h http://commits.kde.org/krita/54282a72cee6256f29be9970793b32f6ffae6aa1
The bug should now be fixed in kazakov/memory-optimizations branch. If you see the problem again, please reopen the bug! :)
Git commit 5884065cb3fe96d294387e3e436c7b6be4da03a8 by Dmitry Kazakov. Committed on 20/07/2016 at 14:00. Pushed by dkazakov into branch 'kazakov/memory-optimizations'. Don't keep the default tile data blocked from swapping Summary: We don't access the raw data of it usually. And is cases we do we should block it separately. This patch is needed to be able to migrate the leftover of tiles to the new pool when a document is closed. Release all the tile pools forcefully when a document is closed This approach is a bit hackish, but it is the best thing we can do. When the document is closed and the pool still contains a few tiles, we artificially "swap-out" the tiles into a QList, purge the data in the tile data pools and "swap-in" the tiles back. Surely, we will not get an ACM award for this solution, but at least it works ;) Related: bug 364848, bug 364848 Implement data pool for the chunks in openGL canvas updates This patch implements KisTextureTileInfoPool. A special object that keeps track of all the chunks allocated during the openGL canvas updates. This class is also capable of tracking multiple openGL tile sizes and color space pixel sizes. It should fix the most of the memory fragmentation problems, especially on Windows. Fix warning Merge remote-tracking branch 'origin/master' into kazakov/memory-optimizations Test Plan: Open any **huge image** in Krita and try to work with it, Krita should not consume more memory with time. The RAM shouldn't also grow with reopening the same large image multiple times. Well, it will grow anyway, but not much. Reviewers: rempt Subscribers: dkazakov Differential Revision: https://phabricator.kde.org/D2236 http://commits.kde.org/krita/5884065cb3fe96d294387e3e436c7b6be4da03a8