G’day! Another bug to SMASH! The fill tool, in comparison to older versions takes significantly longer to fill larger areas than it had before. When I was using the Oct 7 2020 build, if I to filled in an area that wasn’t properly enclosed, the entire canvas (or more) filled instantly (which is normal). But when this occurs with the MAR 26 build, it takes around a good 3 seconds to fill all the way (the software freezes for a few seconds). This is important because it decreases the efficiency of the software. If I didn’t expect it to fill the entire canvas, I am thrown off “balance”. Or has this been made known yet?
@JoeyH Unfortunately it’s not exactly a bug but rather that the algorithm had to be changed to add the capability to fill other layers from the active one and performance suffered as a result.
This has already been discussed that it requires to become a bit more efficient, but I’m afraid it will take time to recover the previous speed that we had once and quite frankly I personally don’t know how this could be improved, so a developer would need to comment regarding this 
.
I see. As long as it doesn’t corrupt anything too much, I suppose it isn’t the worst of problems. I have trust the developers know what they’re doing; Thank you!
@JoeyH I wish I could give you a better alternative, however consider that the dev builds are not final, so those can always improve. If they don’t the next version will. As mentioned performance is important for us but it’s always a balancing act between that and usability.
On the other hand it’s better to always check that your lineart is closed to avoid extra computing time due to a mistaken fill.
1 Like
It is not a bug as @JoseMoreno says. There are two reasons main for this. The first is the new expand fill feature, which can increase the time by a not-insignificant amount. Unchecking the “Expand fill” option will disable this and make it slightly faster. The second thing which makes the fill slower is that all nightly builds are built in “Debug mode”. This includes more checks, less compiler optimizations, and debug symbols, all of which help us diagnose serious issues (crashes, freezing, etc.). After briefly testing, it looks to me that it just about doubles the fill time. The latter issue will go away when a new stable version is released.
It remains to be seen how much the expand fill can be optimized. The current flood fill algorithm is already one of the best ways to implement that feature, so I don’t expect there to be any huge gains in speed without adding hardware acceleration support, which is unlikely to happen ever unless we integrate a third-party library to do this (which I have considered, but is not happening anytime soon and is not a simple change).
1 Like
Understood! Thank you for the detailed explanations!
Maybe someday I can help. Only God knows if THAT could happen.
I’ve been working on the performance of our floodfill algorithm with and without expand enabled. Please try out this build and let me know what you think.
Win64: pencil2d-win64-86-2022-04-02.zip - Google Drive
Linux: pencil2d-linux-86-2022-04-02.AppImage - Google Drive
Mac OS: pencil2d-mac-86-2022-04-02.zip - Google Drive
2 Likes
More improvements:
Win64: pencil2d-win64-87-2022-04-03.zip - Google Drive
Linux: pencil2d-linux-87-2022-04-03.AppImage - Google Drive
Mac OS: pencil2d-mac-87-2022-04-03.zip - Google Drive
This topic was automatically closed 42 days after the last reply. New replies are no longer allowed.