Created attachment 113564 [details] Red area for testing I received this complain about Krita's Contiguous Selection Tool being too slow from the artist Goshaag who drew us many lovely Kiki fanarts. When he was drawing this: https://twitter.com/goshaag/status/1011276763475922944 He encountered many slowdowns while his machine is nowhere low performance. Of everything the most problematic one being Krita's Contiguous Selection Tool is just too slow. I've tested Krita's Contiguous Selection Tool with the file I attached. I tested against Krita, GIMP and Paint.NET. Krita needed 1.5 seconds to finish a Contiguous Selection on his XEON L5410 4GB machine. It took about the same amount of time on my i7-6560U 16GB machine to do the same, indicating it being slow by its nature. GIMP can do it with its similar "Fuzzy Select Tool" instantly, and reportedly did Paint.NET and SAI. "Krita's Magic Wand Tool is too slow" is one of the most common reason I heard for which people stopped using Krita. I think people from PS and SAI expect the tool to do the job in-a-snap just like in those programs, especially for those whose workflow depend heavily on such a tool. Is it possible to improve its performance? Thank you!
Nul à chier ce systeme !
Weird, it's completely instant on my system. I'm not sure what more we could do, we already spent a couple of rounds optimizing the flood-fill algorithm, which is what this uses.
Krita version: 4.2.0-pre-alpha (git 5120b70) QT version: 5.9.3 GPU: Nvidia GeForce 940M, using OpenGL Windows 10 Gimp version: Gimp 2.8 I checked the test image in the size of the original and resized 2x (scaled to 7016 px) and 4x (14032 px)to properly measure the lag. 1) 1x: Gimp - instant (less than 0.6s), Krita: 1.5 s? not instant (nearly, but the delay is more visible than in Gimp) 2) 2x: Gimp - 1.7s, Krita 3.8s 3) 4x: Gimp - 5s, Krita 12s (my first try made my PC unresponsive, and the second (after restarting Krita) took 40s, but every other took around 12s) To sum up: Magic Selection Tool from Gimp is around 2x faster than Krita's Contiguous Selection Tool.
(In reply to Tymond from comment #3) > Krita version: 4.2.0-pre-alpha (git 5120b70) > QT version: 5.9.3 > GPU: Nvidia GeForce 940M, using OpenGL > Windows 10 > Gimp version: Gimp 2.8 > > > > I checked the test image in the size of the original and resized 2x (scaled > to 7016 px) and 4x (14032 px)to properly measure the lag. > > 1) 1x: Gimp - instant (less than 0.6s), Krita: 1.5 s? not instant (nearly, > but the delay is more visible than in Gimp) > > 2) 2x: Gimp - 1.7s, Krita 3.8s > > 3) 4x: Gimp - 5s, Krita 12s (my first try made my PC unresponsive, and the > second (after restarting Krita) took 40s, but every other took around 12s) > > > To sum up: Magic Selection Tool from Gimp is around 2x faster than Krita's > Contiguous Selection Tool. Thank you for the comparison testing! :)
I am setting this to wishlist considering that while it is annoying, it would require rewriting the floodfill algorithm.
I just checked, and Gimp 2.10 is actually slower than Krita. I did notice we don't multithread the floodfill painter, and if that were possible, we might be able to make it faster without dropping the algorithm and trying for something new. (Not that that would be easy: we already have optimized everything we could out of it...)
That'd be Great! On behalf of my fellow artists from PS and SAI, hopefully we can get this under 250ms someday. That'll allow them to work comfortably in Krita.
Created attachment 127868 [details] Selection tool To add to this, I did some testing to the best of my ability, and came up with the attached figures for each program at 3 different canvas sizes. I tried to make all tests as consistent as possible, with the same color space and same file. Single layer, 0 or no threshold/fuzzy, no post-expansion or feathering. Measured from the first frame the mouse is down, to the first frame of the marching ants showing up. Krita has both a 'standard' and -500ms version listed as someone told me in a different bug that it has a self-imposed 500ms delay for an unknown reason.
Thanks for measuring! Tbh, from your table it looks like it's a bit slower than Gimp and adds two 500ms delays, not one - not the 500x500 example where Krita is ridiculously slow, and in all columns it is very similar to value (Gimp + 1000).
Git commit c416124848d52a9b82ef275e24e3aaa1f45a3004 by Dmitry Kazakov. Committed on 29/04/2020 at 15:04. Pushed by dkazakov into branch 'master'. Remove 500ms delay between selection creation and cretion of marching ants This delay was originally introduced to not interfere with painting, which (in 2013) was done directly over the ants. Now we have overlay mask functionality, therefore this delay is not needed anymore. There is still a short visible delay. It is cause but the outline genration algorithm is really slow. Perhaps we should also try to fix speed when working on bug 419240. Related: bug 419738 M +1 -1 libs/ui/kis_selection_decoration.cc https://invent.kde.org/kde/krita/commit/c416124848d52a9b82ef275e24e3aaa1f45a3004
Git commit ca1399e9bb2886b1ad1378ddcc719dc65957d722 by Dmitry Kazakov. Committed on 29/04/2020 at 15:07. Pushed by dkazakov into branch 'krita/4.3'. Remove 500ms delay between selection creation and cretion of marching ants This delay was originally introduced to not interfere with painting, which (in 2013) was done directly over the ants. Now we have overlay mask functionality, therefore this delay is not needed anymore. There is still a short visible delay. It is cause but the outline genration algorithm is really slow. Perhaps we should also try to fix speed when working on bug 419240. Related: bug 419738 M +1 -1 libs/ui/kis_selection_decoration.cc https://invent.kde.org/kde/krita/commit/ca1399e9bb2886b1ad1378ddcc719dc65957d722
Git commit 036be0f51229f83ba06b39a4cd27769899775f65 by Dmitry Kazakov. Committed on 29/04/2020 at 15:53. Pushed by dkazakov into branch 'master'. Don't update selection mask when it is not set as overlay It removes about 200ms delay on creating any kind of selection M +7 -0 libs/image/kis_selection_mask.cpp M +3 -0 libs/image/kis_selection_mask.h https://invent.kde.org/kde/krita/commit/036be0f51229f83ba06b39a4cd27769899775f65
Git commit f6d6dd661fd00cf5b566face1dc4895508a83bee by Dmitry Kazakov. Committed on 29/04/2020 at 15:54. Pushed by dkazakov into branch 'krita/4.3'. Don't update selection mask when it is not set as overlay It removes about 200ms delay on creating any kind of selection M +7 -0 libs/image/kis_selection_mask.cpp M +3 -0 libs/image/kis_selection_mask.h https://invent.kde.org/kde/krita/commit/f6d6dd661fd00cf5b566face1dc4895508a83bee
Hi, Tyson! Could you please check this package (are you using Windows?): https://yadi.sk/d/mxpMq5O_BZUPMw It has both selection fixes, so creating a flood selection for your test image takes about 100ms. Is the speed of the package okay or it is still slow for you?
Hi, Tyson! If you need an AppImage, now there is a prebuilt version: https://binary-factory.kde.org/job/Krita_Stable_Appimage_Build/727/
Hi Dmitry, I just tested them both on Windows and Linux. The difference was night and day. Thank you! While your patch improved the speed significantly, it's still very slow compare to other apps. However, Krita's Fill Tool has a "Fast Mode" checkbox, it fills as fast as other tools. That's the speed we expect from a "Magic Wand" tool. Can we get that option for Krita Contiguous Selection Tool? Thanks!
Hi, Tyson! The problem is that we do already use "Fast Mode" there :) I have one question, do you have "Anti-aliasing" checkbox enabled? I have checked that code an it seems like **unchecking** it makes selection speed about 3-4 times slower (due to additional pass).
I mean you need to **enable** antialiasing to make selection faster (which is a bit counter-intuitive).
Hi, Tyson! Could you test this package: https://yadi.sk/d/R4HMo5aQEhVXiQ It makes "make-aliased" pass about 3 times faster. But it applies only to a case when "Anti-alias" checkbox is **unchecked***.
Hi Dmitry, Thank you for the second patched version. It was not until 3 AM today was I able to download the file from Yandex. I think it could be network slowdown in Europe during busy hours with all those pandemic induced bandwidth usage. I use Linux, but I maintain a second drive just for test purpose and flashing firmwares. Maybe you can give me appimage links from now on to save me a reboot and the eyesores looking at Windows Cleartype. :D Now the patched version (DK2). It both worked and did not work for me: For small pictures, it was definitely working. It selects an area in a blink. Fastest speed I ever saw. For large pictures it was a very different story. Use the the 4.3 splash for example, and select a small color patch: https://tysontan.com/temp/free_software/kiki/electrichearts_20200221A_kiki_b.png It was really, really slow. Much slower than the DK1 build. It doesn't matter where I clicked or how large a color patch is, it'd just slowdown to the same amount. Krita felt like it was taking the whole image into consideration when calculating the effective area. Meanwhile the Fill tool can still fill an area in an instant. This picture has no gradient color, all hard-edged, there is no way it needed to look at the whole picture for a small patch of waterlily. But if I crop the large splash under 1000x1000, then when I select the same area as above, it'd be selected in an instant. Enabling Antialiasing in DK1 build was able to speed up 100 to 200 ms. But in DK2 when the image was large, enable or disable it does make much difference, because it was just to slow to begin with.
Hi, Tyson! Thank you for your explanation. With your test image I seem to be able to reproduce the problem now. I'll check in details tomorrow :) PS: Btw, your new splash screen is really nice! :)
Git commit ab20233c0a89704f06c0077d9e63bb45eb1379ba by Dmitry Kazakov. Committed on 01/05/2020 at 09:42. Pushed by dkazakov into branch 'master'. Fix KisScanlineFill not to tounch point (0,0) on every fill This patch fixes wery slow application of Magic Wand tool on big images. The slowdown happened because KisScanlineFill write-accessed every dst device at position (0,0), when initialized random accessors. It resulted in dst device extent growing too much, therefore a lot of empty pixels had to be porcessed at the later stages of contiguous selection. M +48 -47 libs/image/floodfill/kis_scanline_fill.cpp https://invent.kde.org/kde/krita/commit/ab20233c0a89704f06c0077d9e63bb45eb1379ba
Git commit 75430a75cdf49b84519b1664c4fdcf3cc93d742b by Dmitry Kazakov. Committed on 01/05/2020 at 09:44. Pushed by dkazakov into branch 'krita/4.3'. Fix KisScanlineFill not to tounch point (0,0) on every fill This patch fixes wery slow application of Magic Wand tool on big images. The slowdown happened because KisScanlineFill write-accessed every dst device at position (0,0), when initialized random accessors. It resulted in dst device extent growing too much, therefore a lot of empty pixels had to be porcessed at the later stages of contiguous selection. M +48 -47 libs/image/floodfill/kis_scanline_fill.cpp https://invent.kde.org/kde/krita/commit/75430a75cdf49b84519b1664c4fdcf3cc93d742b
Hi, Tyson! Could you please check this AppImage, the bug should be fixed there: https://yadi.sk/d/WWxIlX_7rcrNng
Thank you Dmitry, this is amazing! Everything can be selected in a snap now, and it's faster than anything I've ever used. This is a game changer, especially for those who use Krita to color their comics. They are going love it! :D
Hehe, great! I will close the bug then. Thanks a lot for testing! :)
Git commit 126608b4e7a3047f5694b28572bc306a01faeb75 by Dmitry Kazakov. Committed on 01/05/2020 at 14:25. Pushed by dkazakov into branch 'master'. [NOT FOR 4.3.0] Remove start position from KisRandomAccessor2 Start posiiton in ctor is not used anywhere, it only causes bugs like 395861, because some code passes default value (0,0) to it, which extends extent of the paint device, to the area, which is not actually modified. It might also fix some troubles with Transform Tool (not tested). M +13 -13 benchmarks/kis_random_iterator_benchmark.cpp M +4 -6 libs/image/KisPrecisePaintDeviceWrapper.cpp M +50 -57 libs/image/floodfill/kis_scanline_fill.cpp M +1 -1 libs/image/kis_cross_device_color_picker.h M +2 -2 libs/image/kis_outline_generator.cpp M +13 -7 libs/image/kis_paint_device.cc M +8 -2 libs/image/kis_paint_device.h M +10 -10 libs/image/kis_paint_device_strategies.h M +15 -15 libs/image/kis_painter.cc M +2 -2 libs/image/kis_painter_blt_multi_fixed.cpp M +2 -2 libs/image/kis_perspectivetransform_worker.cpp M +1 -1 libs/image/kis_random_sub_accessor.cpp M +4 -4 libs/image/kis_transform_worker.cc M +2 -3 libs/image/kis_wrapped_random_accessor.cpp M +0 -1 libs/image/kis_wrapped_random_accessor.h M +1 -1 libs/image/krita_utils.cpp M +1 -1 libs/image/layerstyles/kis_ls_utils.cpp M +2 -2 libs/image/lazybrush/KisWatershedWorker.cpp M +4 -4 libs/image/lazybrush/kis_lazy_fill_capacity_map.h M +3 -3 libs/image/tests/kis_iterator_benchmark.cpp M +4 -4 libs/image/tests/kis_iterator_test.cpp M +3 -3 libs/image/tests/kis_iterators_ng_test.cpp M +2 -2 libs/image/tests/kis_paint_device_test.cpp M +1 -1 libs/image/tests/kis_transform_worker_test.cpp M +5 -2 libs/image/tiles3/kis_random_accessor.cc M +1 -1 libs/image/tiles3/kis_random_accessor.h M +2 -2 libs/ui/tool/strokes/KisMaskingBrushRenderer.cpp M +2 -2 plugins/extensions/layersplit/layersplit.cpp M +4 -4 plugins/extensions/qmic/kis_qmic_simple_convertor.cpp M +1 -1 plugins/filters/embossfilter/kis_emboss_filter.cpp M +1 -1 plugins/filters/halftone/kis_halftone_filter.cpp M +1 -1 plugins/filters/raindropsfilter/kis_raindrops_filter.cpp M +1 -1 plugins/filters/randompickfilter/randompickfilter.cpp M +1 -1 plugins/paintops/colorsmudge/kis_smudge_radius_option.cpp M +1 -1 plugins/paintops/hairy/hairy_brush.cpp M +1 -1 plugins/paintops/particle/particle_brush.cpp M +3 -3 plugins/paintops/spray/spray_brush.cpp M +2 -2 plugins/tools/selectiontools/KisMagneticGraph.h https://invent.kde.org/kde/krita/commit/126608b4e7a3047f5694b28572bc306a01faeb75
Git commit 10cad8b7a4721b33c98923beb354e5457b5cc48d by Dmitry Kazakov. Committed on 02/06/2020 at 10:04. Pushed by dkazakov into branch 'krita/4.3'. [NOT FOR 4.3.0] Remove start position from KisRandomAccessor2 Start posiiton in ctor is not used anywhere, it only causes bugs like 395861, because some code passes default value (0,0) to it, which extends extent of the paint device, to the area, which is not actually modified. It might also fix some troubles with Transform Tool (not tested). M +13 -13 benchmarks/kis_random_iterator_benchmark.cpp M +4 -6 libs/image/KisPrecisePaintDeviceWrapper.cpp M +50 -57 libs/image/floodfill/kis_scanline_fill.cpp M +1 -1 libs/image/kis_cross_device_color_picker.h M +2 -2 libs/image/kis_outline_generator.cpp M +13 -7 libs/image/kis_paint_device.cc M +8 -2 libs/image/kis_paint_device.h M +10 -10 libs/image/kis_paint_device_strategies.h M +15 -15 libs/image/kis_painter.cc M +2 -2 libs/image/kis_painter_blt_multi_fixed.cpp M +2 -2 libs/image/kis_perspectivetransform_worker.cpp M +1 -1 libs/image/kis_random_sub_accessor.cpp M +4 -4 libs/image/kis_transform_worker.cc M +2 -3 libs/image/kis_wrapped_random_accessor.cpp M +0 -1 libs/image/kis_wrapped_random_accessor.h M +1 -1 libs/image/krita_utils.cpp M +1 -1 libs/image/layerstyles/kis_ls_utils.cpp M +2 -2 libs/image/lazybrush/KisWatershedWorker.cpp M +4 -4 libs/image/lazybrush/kis_lazy_fill_capacity_map.h M +3 -3 libs/image/tests/kis_iterator_benchmark.cpp M +4 -4 libs/image/tests/kis_iterator_test.cpp M +3 -3 libs/image/tests/kis_iterators_ng_test.cpp M +2 -2 libs/image/tests/kis_paint_device_test.cpp M +1 -1 libs/image/tests/kis_transform_worker_test.cpp M +5 -2 libs/image/tiles3/kis_random_accessor.cc M +1 -1 libs/image/tiles3/kis_random_accessor.h M +2 -2 libs/ui/tool/strokes/KisMaskingBrushRenderer.cpp M +2 -2 plugins/extensions/layersplit/layersplit.cpp M +4 -4 plugins/extensions/qmic/kis_qmic_simple_convertor.cpp M +1 -1 plugins/filters/embossfilter/kis_emboss_filter.cpp M +1 -1 plugins/filters/halftone/kis_halftone_filter.cpp M +1 -1 plugins/filters/raindropsfilter/kis_raindrops_filter.cpp M +1 -1 plugins/filters/randompickfilter/randompickfilter.cpp M +1 -1 plugins/paintops/colorsmudge/kis_smudge_radius_option.cpp M +1 -1 plugins/paintops/hairy/hairy_brush.cpp M +1 -1 plugins/paintops/particle/particle_brush.cpp M +3 -3 plugins/paintops/spray/spray_brush.cpp M +2 -2 plugins/tools/selectiontools/KisMagneticGraph.h https://invent.kde.org/graphics/krita/commit/10cad8b7a4721b33c98923beb354e5457b5cc48d