Created attachment 152151 [details] bug SUMMARY 1.create a new file 2.fill a color on canvas 3.we can find that the thumbnail larger
That is the same bug as bug 457562. Perhaps we should give it some priority...
*** Bug 457562 has been marked as a duplicate of this bug. ***
Git commit 9b7318c13298e2fc52b52ac0d760a62152d4a838 by Dmitry Kazakov. Committed on 20/09/2022 at 08:24. Pushed by dkazakov into branch 'master'. Make sure that thumbnails are generated from exactBounds() Now the layer thumbnails are generated only at the very end of the stroke, that is, when the image is idle. It makes it possible to use more expensive exactBounds() routine for the thumbnails update. M +1 -1 libs/image/kis_paint_device.cc M +15 -4 plugins/dockers/layerdocker/LayerBox.cpp M +5 -1 plugins/dockers/layerdocker/LayerBox.h https://invent.kde.org/graphics/krita/commit/9b7318c13298e2fc52b52ac0d760a62152d4a838
Hi, I've find a minor regression after the fix: Erase on the layer will add empty space on thumbnail, but did not change the proportion, which cause thumbnail distort. Step to reproduce: 1) Draw a circle on the right side of canvas, then erase on the left side of canvas 2) We can see the circle layer thumbnail distort krita-5.2.0-prealpha-c79f718865.appimage
Reopening, because it was reverted due to crashes (see bug 459510)
Git commit 1245a9a09ed53f4027ddb5a22ea1c9a3ecf46a10 by Dmitry Kazakov. Committed on 11/11/2022 at 12:56. Pushed by dkazakov into branch 'master'. Make sure that thumbnails are generated from exactBounds() Now the layer thumbnails are generated only at the very end of the stroke, that is, when the image is idle. It makes it possible to use more expensive exactBounds() routine for the thumbnails update. M +1 -1 libs/image/kis_paint_device.cc M +15 -4 plugins/dockers/layerdocker/LayerBox.cpp M +5 -1 plugins/dockers/layerdocker/LayerBox.h https://invent.kde.org/graphics/krita/commit/1245a9a09ed53f4027ddb5a22ea1c9a3ecf46a10
*** Bug 463186 has been marked as a duplicate of this bug. ***
*** Bug 419830 has been marked as a duplicate of this bug. ***
Isn't the thumbnail generation before the patch is technically more 'correct' way? Because the pixel data is still there on the layer even it it's transparent and invisible. Not that I have a big problem with the patch, but I liked the fact that I could judge the actual layer size with the thumbnail...
(In reply to acc4commissions from comment #9) > Isn't the thumbnail generation before the patch is technically more > 'correct' way? Because the pixel data is still there on the layer even it > it's transparent and invisible. > Not that I have a big problem with the patch, but I liked the fact that I > could judge the actual layer size with the thumbnail... As a painter, I wouldn't care about this until I find my file is abnormally heavy for all it contains. Shouldn't the layer be resized when empty ? Maybe a manual action could be triggered ("compress file") at user's will ? Or a dev option to see the real size of the layer in the thumbnails. For me, as a painter, having inefficient thumbnails is a real concern. I would enjoy a file that is just as big as necessary and If I find my file too big because I know of this issue I would crop the file if it shrinks its size.