SUMMARY STEPS TO REPRODUCE 1. load any image. (preferably larger ones) 2. Create a filter mask, and select the Raindrop filter. 3. freeze. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Using the 4.2.7-beta1 with Linux and a 2000 x 2000 px image, it takes 90 seconds to complete the Raindrop filter. During this time, I can open the brush editor and the settings window, i.e. there is no 'freeze'. CPU usage is at about 60-80% while this is happening. With Windows 10 on the same machine, it takes 8 minutes to complete the Raindrop filter and there is no visible output for the first four minutes. (The canvas is updated in 500 x 500 px blocks and this seems to be common for most filters but most filters are not this slow.) It makes no difference if I use OpenGL or Angle. During this time, there is no freeze and CPU usage is about 12%.
(In reply to Ahab Greybeard from comment #1) > Using the 4.2.7-beta1 with Linux and a 2000 x 2000 px image, it takes 90 > seconds to complete the Raindrop filter. During this time, I can open the > brush editor and the settings window, i.e. there is no 'freeze'. CPU usage > is at about 60-80% while this is happening. > > With Windows 10 on the same machine, it takes 8 minutes to complete the > Raindrop filter and there is no visible output for the first four minutes. > (The canvas is updated in 500 x 500 px blocks and this seems to be common > for most filters but most filters are not this slow.) > It makes no difference if I use OpenGL or Angle. > During this time, there is no freeze and CPU usage is about 12%. Ok. But it's not an expected behavior, is it?
It's certainly not reasonable at first sight, especially on Windows 10. (Which OS are you using?) It may be that the Raindrop filter is famously hungry for CPU resources, I've no idea. A developer with more knowledge of those sorts of details may be able to shed more light on this.
Yes, the raindrops filter cannot be threaded, so it needs to calculate its effects for the whole image on one CPU core. That's something that cannot be changed, though.
@Boud: The truly strange thing is that the more cores that are allocated to krita then the worse the performance is. For my previous image example, varying the cores allocated: Linux- 6/8 cores takes 90 seconds - 1/8 cores takes 20 seconds. Windows 10- 6/8 cores takes 8 minutes - 1/8 cores takes 20 seconds. (8/8 cores is slightly faster than 6/8 which is the worst case for me.) I don't know if this is something that can be 'fixed' or if it just has to be accepted. (The Windows 10 results are very puzzling.) @acc4commissions: If you need to use the Raindrop filter then it seems to be worth trying it with only one core allocated.
(In reply to Ahab Greybeard from comment #5) > @acc4commissions: If you need to use the Raindrop filter then it seems to be > worth trying it with only one core allocated. I don't need to use Raindrop filter. It's just that I have to experience freeze for minutes every time I accidently click the raindrop filter in the list when creating filter mask.
Git commit e811af0858972912b07d163c1c088fb174c6fa4c by Wolthera van Hövell tot Westerflier. Committed on 07/10/2019 at 15:23. Pushed by woltherav into branch 'master'. Disable adjustmentlayer support on the raindrop filter. By rule of thumb, filters that cannot multithread should not be allowed as adjustment layers, (which are, afaik, multithreaded) so I am half wodering if we should not somehow hardcode whether or not adjustment layers are supported based on the availability of multithread, but regardless, it's best to disable adjustment layers on this specific filter. M +1 -1 plugins/filters/raindropsfilter/kis_raindrops_filter.cpp https://invent.kde.org/kde/krita/commit/e811af0858972912b07d163c1c088fb174c6fa4c
Git commit da5a240daf90407769772eeeb01ee87b1ff88705 by Boudewijn Rempt, on behalf of Wolthera van Hövell tot Westerflier. Committed on 09/10/2019 at 08:40. Pushed by rempt into branch 'krita/4.2'. Disable adjustmentlayer support on the raindrop filter. By rule of thumb, filters that cannot multithread should not be allowed as adjustment layers, (which are, afaik, multithreaded) so I am half wodering if we should not somehow hardcode whether or not adjustment layers are supported based on the availability of multithread, but regardless, it's best to disable adjustment layers on this specific filter. (cherry picked from commit e811af0858972912b07d163c1c088fb174c6fa4c) M +1 -1 plugins/filters/raindropsfilter/kis_raindrops_filter.cpp https://invent.kde.org/kde/krita/commit/da5a240daf90407769772eeeb01ee87b1ff88705