[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 Boudewijn Rempt changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED CC||b...@valdyas.org --- Comment #12 from Boudewijn Rempt --- If it's fixed, I'll close the bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 --- Comment #11 from acc4commissi...@gmail.com --- Ok. But since it's fixed anyway I guess I'm happy with this for now. ;D -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 --- Comment #10 from Tymond --- No, because the point of that new feature was to get a new feature for the Fill Tool, not to fix this bug, unfortunately. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 --- Comment #9 from acc4commissi...@gmail.com --- Ok. So did that change also fixed the behavior with the other tools? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 --- Comment #8 from Tymond --- 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=165355 - specifically post showing the difference in Fill Tool in different programs: https://forum.kde.org/viewtopic.php?f=288=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=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...). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 --- Comment #7 from acc4commissi...@gmail.com --- @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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 --- Comment #6 from acc4commissi...@gmail.com --- (In reply to Tymond from comment #5) > @acc4commissi...@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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 Tymond changed: What|Removed |Added CC||tamtamy.tym...@gmail.com --- Comment #5 from Tymond --- @acc4commissi...@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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 --- Comment #4 from acc4commissi...@gmail.com --- This still happens in 4.3.0, but not in the nightly stable builds. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 --- Comment #3 from acc4commissi...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 --- Comment #2 from acc4commissi...@gmail.com --- 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 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 418071] Moving layers that has any area made with select>fill is slow to move with move tool
https://bugs.kde.org/show_bug.cgi?id=418071 Rebecca Breu changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED CC||rebe...@rbreu.de --- Comment #1 from Rebecca Breu --- 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. -- You are receiving this mail because: You are watching all bug changes.
