Krita uses a lot of memory when the image size is changed multiple times.
Steps to Reproduce:
1. Create a new image of 400x400 pixels
2. Change the image size to 40x40
3. Change the image size to 400x400
4. Repeat 2 - 3 a few more times
Lot of memory in use. In my system, used memory were ~15 GB and still growing.
Also, the resizing process takes longer to complete.
Normal memory usage.
Attached processed valgrind massif tool output while downscaling to 40x40 and scaling to 400x400 an image with original size of 400x400 @8-bit. I repeat this process 2 times. As result, 9GB of memory are consumed.
Created attachment 83766 [details]
Yeah, it looks something leaks there... :(
Let's check with memcheck as well.
What seems to happen is that the layer grows and grows. I just checked using gdb and the boundrect in KisTransformWorker::transforPass is 0, 0, 45807, 4479
Git commit 7d412c717ad2b9982e9c59699985e54c7070c3fa by Dmitry Kazakov.
Committed on 27/11/2013 at 06:09.
Pushed by dkazakov into branch 'master'.
Fix Transorm Worker to shrink device bounds when doing scale-down
When doing a scale-down a great portion of the image becomes filled
with the default pixel. If the default pixel of a paint device is not
fully transparent, then the exactBounds() will not shrink automatically.
That is why we need to purge() all the default tiles of the paint device
Note: the Crop visitor needs *not* the same stuff, since
KisPaintDevice::crop() calls KisDataManager::setExtent() which
explicitly drops all the tiles outside of the requested area.
Special thanks to Boud, who has found the real cause of the bug!
M +5 -0 krita/image/kis_paint_device.cc
M +6 -0 krita/image/kis_paint_device.h
M +6 -0 krita/image/kis_transform_worker.cc
M +2 -0 krita/image/tiles3/kis_tiled_data_manager.cc