https://bugs.kde.org/show_bug.cgi?id=414903
--- Comment #5 from b...@beuc.net --- > Can you please provide a file that shows the issue? Attached. Both layers have extra space. Initially: 100MB RAM (says Krita title bar) Layers > Transform all layers > Scale" (no-op same-size): trims some layers but interestingly some not, no idea why; 70MB RAM Select opaque > crop individual: 40MB RAM > Also, if I understand @beuc correctly, the problem is that Krita counts > pixels changed by using eraser on already transparent pixels as inside > the bounds(), is that correct? I believe that's one of the several reasons why unoptimized blank space lie around. Fixing this particular occurrence does not fix the general issue IMHO, and more importantly it does not fix existing documents. > that's why Layer -> crop to image size didn't work, > because the transparent areas were already on the image). Do you mean "Image > Trim to Image Size"? AFAICS this only trims hidden layer pixels outside the image area (e.g. when finishing a stroke outside of image). No effect in this test case. > @boud if you're talking about autocropping the actual content of layers on > saving, I'm really really strongly against it Would you mind elaborating on why? The main reason I opened this bug rather than directly attempt a patch is because I suspected this might be an issue, though I have no precise idea on why (concurrency issue when saving in the background maybe?). > fortunately I believe @beuc has something else on mind, as in, recounting > bounds() to make sure all transparent areas has been cropped out. No, auto-cropping on save is exactly what I had in mind. (I'm not sure I understand what you're proposing though ;)) I liked the solution because I think it safely optimizes existing documents without having to teach users about it. -- You are receiving this mail because: You are watching all bug changes.
