SUMMARY Happens in both nightly git 369d552, 4.2.8. Moving layers that has any area that made with select>fill is much slower to move with move tool compared to the layer that has only freehand brushworks. STEPS TO REPRODUCE 1. Select any layer > Select any area with any Selection Tool > Fill with Background or Foreground Color > Deselect 1-1. Try to move the layer with Move Tool 1-2. Clear(erase) the layer > paint the same amount of area with Freehand Brush Tool > Try to move the layer with Move Tool OBSERVED RESULT 1-1 is much laggy and slower to move compared to the case of 1-2, as if you are trying to move the layer about the size of the entire canvas filled with color. EXPECTED RESULT There shouldn't be any difference. SOFTWARE/OS VERSIONS Windows: Win7 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION * If you use Fill tool to fill inside any selection it takes a long time to finish(as if you are trying to fill the entire canvas). I think it's all the same issue.
I can confirm this on the 4.2.8 appimage. If I look at the little layer previews, what seems to be happening is that the stored section of a layer with brush strokes on it is cropped down to the area that has actual paint on it, whereas the layer where I bucket filled a selection is the size of the whole image but with a lot of transparent space. There's something that recalculates stored area when I paint with a brush, but for some reason it won't do that if I started with a bucked filled selection — even if I add brush strokes afterwards. I can only make the stored section larger by painting outside of the canvas border.
Turns out, it also happens with the brush tool of any of that sort, when you 'painted' far outside the selections. Looks like Krita doesn't restrict the area with the selection(although it appears to be on the canvas), and take all the touched/filled/etc area into the mix when doing something with that layer. Tested in git 79cc75e
This seems to have been fixed now(I'm on git 5e750f3). Did you intentionally fix this? Plz do not just mark this as resolved, because I'm really not sure.
This still happens in 4.3.0, but not in the nightly stable builds.
@acc4commissions@gmail.com the change probably comes from my changes to the Fill Tool and Contiguous Selection Tool. If you select "use selection as boundary", it will only paint in the area inside the selection. If you unselect it, it will paint everything and only later cuts out the unselected areas. There is some difference in behaviour that comes from this feature. In terms of slowness, this new implementation of filling doesn't have the downside that the old implementation (called when you have the checkboxes unchecked) had, which is painting/changing the whole canvas. So to sum up, it wasn't intentionally fixed per se but if you have the checkbox checked, you should be using the version of the fill tool that behaves in the way that doesn't trigger this specific bug. Please check if this explanation (that the behaviour and speed is different depending on the checkbox) is consistent with your findings. I believe this bug should be left open since it would be good if the standard/old version of the fill tool and the freehand brush tool and other tools had some remedies in place for this situation. For example fill tool could have some recalculating of the size of the paint device (cutting off the unused space) after filling.
(In reply to Tymond from comment #5) > @acc4commissions@gmail.com the change probably comes from my changes to the > Fill Tool and Contiguous Selection Tool. If you select "use selection as > boundary", it will only paint in the area inside the selection. If you > unselect it, it will paint everything and only later cuts out the unselected > areas. There is some difference in behaviour that comes from this feature. > In terms of slowness, this new implementation of filling doesn't have the > downside that the old implementation (called when you have the checkboxes > unchecked) had, which is painting/changing the whole canvas. So to sum up, > it wasn't intentionally fixed per se but if you have the checkbox checked, > you should be using the version of the fill tool that behaves in the way > that doesn't trigger this specific bug. > > Please check if this explanation (that the behaviour and speed is different > depending on the checkbox) is consistent with your findings. > > I believe this bug should be left open since it would be good if the > standard/old version of the fill tool and the freehand brush tool and other > tools had some remedies in place for this situation. For example fill tool > could have some recalculating of the size of the paint device (cutting off > the unused space) after filling. I want to test but as I mentioned in https://bugs.kde.org/show_bug.cgi?id=423470 Krita crashes when I try to use Fill tool. I'm waiting for that bug to be fixed in the nightlies. In my previous observation, I used 'Fill with Foreground Color'(Shift+Backspace) and 'Fill with Foreground Color'(Backspace) via shortcut keys, and the Brush tool to see what happens when I touch a large(which means, far from the selection) area with it. Krita didn't lag when I'm moving the resulting layer with Move tool on both cases.
@Tymond I tested with git eccf4e1, and in the case I fill the selection with Fill tool without selecting "use selection as boundary", it tried to fill the entire canvas and caused this bug(The layer thumbnail was also showing the size of the entire canvas). In all the other cases, in which I used 1 Fill Tool with the "use selection as boundary" option selected 2 'Fill with Foreground Color'(Backspace), 'Fill with Background Color'(Shift+Backspace) 3 Freehand Brush Tool, Multibrush Tool 4 Grdient Tool 5 Line Too, Rectangle Tool, and all the other tools of that sort -they all limited the painted area whitin the selection, as it's originally supposed to be. If this bahavior is consistent with what you intended to achieve with your fix, then I guess it's properly fixed. * But in that case I have to ask why you need the "use selection as boundary" as a 'selectable' option in the first place?; It's way faster to fill the area using selection as boundary and restricting the filled area within the selection is how it's supposed to be anyway, otherwise I wouldn't have wrote this bug report.
This actually changes the behaviour of the Fill Tool when you have more than one selection, and sometimes even if you have just one but with a specific type of content. Please refer to this forum post: https://forum.kde.org/viewtopic.php?f=288&t=165355 - specifically post showing the difference in Fill Tool in different programs: https://forum.kde.org/viewtopic.php?f=288&t=165355#p430706 (on the left: Krita (checkbox unchecked), Painstorm, Gimp, on the right: Photoshop, CSP, SAI, and the new behaviour: Krita with checkbox checked) and the specific description of the feature (with a few examples that differentiate between those two behaviours in post https://forum.kde.org/viewtopic.php?f=288&t=165355#p430735 (it's "Feature 1"). So basically since it changes the outcome, it cannot be always assumed. Since the old behaviour is when the checkbox is unchecked, then the uncheckedness is default (or at least should be...).
Ok. So did that change also fixed the behavior with the other tools?
No, because the point of that new feature was to get a new feature for the Fill Tool, not to fix this bug, unfortunately.
Ok. But since it's fixed anyway I guess I'm happy with this for now. ;D
If it's fixed, I'll close the bug.