Thanks a lot for your testing. I thought it was just bad luck with my configuration. Maybe one of the developer will have some idea about this.
Hi, can you make a screenshot of your fill options and tell us where are you clicking?
Fill operations are complex and heavy with Krita, and your image is almost 6000x7000 pixels, with 16-bit color format.
Please show a screenshot with the fill tool options.
The fill tool always was slow in krita. There was a fast mode that one could select by checking a box but I remove it and now the fast mode only applies if some combination of options applies (which are the same as before but now it is implicit instead of explicit): use the current layer as reference, don’t use pattern, don’t use selection, use 100% spread, uncheck “use selection as boundary”), don’t use postprocessing (antialias, grow, feather). I think that was all.
See if that combination improves the performance. Those options rewuire additional compositing steps and are naturally slower.
Edit: all that with the “fill contiguous regions” option.
Edit2: also use 100% opacity and normal blend mode and close gap = 0 (in krita 5.3)
I also think it’s because the OP’s image is really big. A lot of the heavy paint brushes even lag at that size canvas.
Hi
Here’s the options on my side, tested in default RGBA/8bit documents.
Tested on Krita 4.2.8 too with fast mode, there’s no difference, the delay is here.
It’s a similar size than ~A4 600dpi, it’s a common size if you want high quality print.
Grum999
1 Like
For comics work in France, it’s a small size (printed size is A4 and bigger for a lot of comics). I work today in A3 - and even much bigger. As I said, I tested on CSP and Photoshop and, there is no such lag for the same image in 600 dpi !
Well it is known that it is slower. There was a thread here from a couple of years ago about the same issue, comparing to csp.
One possible issue is that it has to work with any color space, so the colors are converted to lab and back when checking color differences. That has some caching so i’m not sure.
Other thing that may sound silly but can add to the lag, at least the perceived lag, is the fact that the fill is performed on mouse up instead of down. At least it can introduce a few ms. Not sure if it would be relevant.
I’ll check if there are more possible causes for the issue. But i’m not sure if that’s something specific of the fill tool.
The perceived lag is easy to see.
Create a 20000x20000 pixels document (I know, it’s big, but it’s easier to “measure” delay)
Draw a 10x10 pixels square on it.
Fill the square.
It takes (on my computer) ~2s to fill the square (or at least to refresh canvas) after mouse button is released.
One thing I’ve noticed: doing an undo on a fill takes a long time too (as doing an undo on a stroke is immediate)
Do the same on a 500x500 pixels document: fill is immediate.
Create a simple square selection (10x10 pixels) will freeze Krita for around ~2s too.
Fill this selection is slow too, but faster than fill the square without selection (~1s I think)
Grum999
Thanks for testing that. To me this result is nonsensical. I will try it too when I’m at the PC. If you are doing a normal fill and the area is limited by the drawn lines, then the duration should be proportional to the filled area.
With the selection, it may be a bit slower and it’s important if the selection is treated as a boundary or not.
I think the culprits of bad performance is how Krita implements the painting layer (the paint device) and manages the color, as Deif_Lou said. I have struggled with this a lot when implementing gap closing fill, basically there’s a performance wall that you can’t cross. I suspect CSP’s implementation is simpler and optimized for the used color format.
1 Like
As far as I know CSP only supports srgb and doesn’t support other colour models like CMYK etc so this might be more simple for it to do color calculations.
2 Likes
yes.
That’s probably why I’ve never noticed this: for small area I always use brushes, and only use fill tool for really big areas and always considered the delay was related to the large area surface
I’m pretty sure in Krita, even if managing color space/color profile per layer, it’s a no-op when you’re working on the same color space/color profile everywhere (note I’ve made all my tests on most basic RGBA/8bit document)
Grum999
1 Like
What I’m referring to here is how Krita is implemented at the low level. Operating on individual pixels (such as is the case with bucket filling) is inherently very inefficient. Paint layers are comprised of many levels of classes working together, interfaces use virtual functions, various strategies, caching. It really is complex. Pixels are at least 4 bytes large, and often more than that, more than you would expect from the color model and depth you selected when creating a new document.
The layers (paint devices) are organized as 64x64 tiles, which is an elegant and general solution, but it forces you to use iterators that are not multithreading friendly and there’s not much opportunity to make things run faster. I spent weeks trying to squeeze even milliseconds of speed here and there and it was a big challenge without also making the code more complex (which is really bad in open source projects, because you want things to be as easy as possible for other and future maintainers).
1 Like
What I meant by perceived lag in that case is the fact that the fill is initiated on mouse up, not down. This may add some ms to the perceived time of filling if the user expects that the fill initiates on mouse down. But it is a perception thing since it actually starts at mouse up. This is not related to the actual lag produced by performance issues.
That was my expectation as well, so I also think that the issue can be on other code other than the flood filk. Maybe there is some place where some rect is computed wrongly and some area greater than the filled region is updated or traversed, or something like that.
That is true but still it should be proportional to the filled area. The number of color differences computed should be the same if the regions are the same, so if it is fast on a small canvas, this should be as fast on a large canvas. Also, the color differences are cached, so if the filled region was of a uniform color, it should be faster since the difference is computed once. We need to check the actual time taken for the flood fill and see if it changes drastically as a function of canvas size. If not, then the issue is on other place.
2 Likes
Ok, I think I have identified the problem. As expected, the fill operation takes the same time but the whole canvas is updated every time. Patch incoming.
9 Likes
I made a merge request with the improvements. Tomorrow I’ll explain what I did. But anyone can try it when the pipeline succeeds: Improve performance of fill tools (!2125) · Merge requests · Graphics / Krita · GitLab
Test builds:
Update: see Fill Tool lag (again and again) - #47 by Deif_Lou
9 Likes
Hi @Deif_Lou
Just tested, yes it works!
Fill + Undo execution time are now the same whatever the document size is (and it’s fast 
)
I’ve tried to take a look to change you’ve made to Krita to fix this problem, I’ve been lost 
It’s seems to be a complex stuff behind.
Note: the fix only impact the fill tool.
Creating a 10x10 pixels selection is still slow.
Fill + undo this selection it too.
I suppose as selection create a new node with all tiles (not only the selected part), there’s no way to improve this?
Grum999
For me simply creating selections is still reasonably fast, but it will depend on the system naturally.
When you say filling a selection is slow, did you have “Use selection as boundary” enabled or not? If it’s disabled, the fill has to process the whole image to see if there are other selections somewhere that are reachable (i.e. no lines blocking the path). In this case, using the boundary should make the fill faster.
For the contiguous selection i will have to ask Dmitry since it uses other mechanism. I mean, the flood fill can be reused but the updating part is what is different.
I’m doing on my tests on a AMD Ryzen 9 3900X 12-Core/24 threads, 64GB DDR4 3600
To be more precise, here an example
- Fill tool, now works fast!
- Selection tools, you can see once selection is made, the “ant walk” is drawn but there’s a delay before the ant walk start to walk (Krita is not responsive during this delay)
- Fill the selection, you can see it take a delay before the fill is visible, and then there’s another delay before being able to get Krita responsive again
- doing undo/redo on selction+fill takes times too
After, I use a big 20000x20000 document, it’s not common and probably not representative of daily usage but it’s the best way to see where there’s performances improvements.
I think there’s no “urgency” and probably it’s better to decorrelate the fix for the fill and a potential fix for the selection.
Do you want I create a bug for the selection part?
Grum999
Well the commands on the edit menu do not use the fill tool so they may be also updating all the canvas.