SUMMARY After testing beta5 i noticed a considerable delay when selecting brush presets in the docker. Once I click on a preset it takes 3 seconds for the new brush to be actually selected and being able to be usable. If i try to use the brush without waiting for the brush to be actually selected nothing is shown on the canvas until the brush is selected, once it appears as selected in the brush preset docker, the canvas is updated with a stroke of the brush I tried to use, but this path is not the same one I did but the shortest one between where I first clicked and where my mouse was the moment the brush appears as selected in the docker. Its good to note that this only happens when selecting the brush in the brush preset docker, when using the / shortcut to go to a previous brush the change is instantly. It might also be relevant that i have many brushes and bundles active in krita right now, around 25 active bundles. Though in beta 2 everything works fine. I tested with several versions, beta 2 everything works fine, no delays at all. the problem seems to first appear in beta 3 and persists on the beta 5 versions even for the the most recent nightly builds (all versions tested down below). I also deleted the sqlite db and opened krita again, 3 times with different builds all with the same result. STEPS TO REPRODUCE 1. Select a brush in the brush preset docker OBSERVED RESULT the brush takes 3 seconds to appear selected in the brush preset and for it to actually be usable to paint EXPECTED RESULT change betwen brushes when selected in the brush preset docker should be instantly. SOFTWARE/OS VERSIONS Windows: Windows 10 TESTED WITH VERSIONS krita-nightly-x64-5.0.0-beta5-0e4b8448bf krita-x64-5.0.0-beta5 krita-nightly-x64-5.0.0-beta5-0e4b8448bf krita-x64-5.0.0-beta3
I don't see this happening with the 5.0.0-beta5 or the Dec 20 5.1.0-prealpha appimages. I don't have many resources added. Can you rename your resources folder to 'krita-many-resources' (or whatever) then start krita to get a default 'mimimal' set of resources, in a freshly created 'krita' folder, then try this again to see if it is because of your large number of resources?
(Change Status)
(In reply to Ahab Greybeard from comment #1) > I don't see this happening with the 5.0.0-beta5 or the Dec 20 5.1.0-prealpha > appimages. > I don't have many resources added. > > Can you rename your resources folder to 'krita-many-resources' (or whatever) > then start krita to get a default 'mimimal' set of resources, in a freshly > created 'krita' folder, then try this again to see if it is because of your > large number of resources? Testing with 5.0.0-beta5-f74b584402 there is indeed no lag when using a a fresh resource folder. However its good to note that the same amount of resources cause no lag at all with 5.0-beta 2, so i still consider it a huge problem. The lag is already noticeable when adding big bundles like Concept & Illustration 1.2 or FizzyFlower Essentials, even if I only have krita 4 bundle and one of these big bundles active the lag happens (not as much as with all my resources). When having only one big bundle deactivating it makes the lag disappear but if you have both bundles active as an example, deactivating both reduces the lag but doesn't stop it. As a test i added both bundles by importing the brushes and presets separately and the result is interesting as i get reduced but inconsistent lag, meaning there is a tiny bit of lag, but only sometimes, other times the change is instant. but still a shorter lag than i get by importing them as bundles.
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
I also met in beta5
Hi, Larissa! Can you clarify a bit, does the delay happen only when you select a brush for the first time in Krita session or every time when you select it? From your note about '/' shortcut, I have a feeling like it should happen only for the first click on the brush
(In reply to Dmitry Kazakov from comment #6) > Hi, Larissa! > > Can you clarify a bit, does the delay happen only when you select a brush > for the first time in Krita session or every time when you select it? From > your note about '/' shortcut, I have a feeling like it should happen only > for the first click on the brush In my case, the first click is 100% triggered. Later, there is a certain probability of triggering. After I select multiple brushes from top to bottom, the probability of triggering is greatly reduced.
(In reply to Dmitry Kazakov from comment #6) > Hi, Larissa! > > Can you clarify a bit, does the delay happen only when you select a brush > for the first time in Krita session or every time when you select it? From > your note about '/' shortcut, I have a feeling like it should happen only > for the first click on the brush Hello, Dmitry! I decided to make some more tests with 5.0 release. Using the same resource folder I used for the previous betas I get constant delay no matter how many times I select the brush. I also have experience the delay in loading the canvas and krita stopped responding for some seconds as I reported in bug 447048. Even with a fresh resource folder, importing bundles have the exact same behavior of constant lag, no matter how many times i select the brush. Testing with a fresh resource folder: - Without any additional bundles -> change between presets is instant, canvas loading is also instant. (using 3000x3000 300ppi canvas for all these tests) - Adding FizzyFlower Essentials and Concept & Illustration 1.2 bundles, without restarting krita -> Things get a bit weird, at first seems like there is no lag when i try to change brushes, however if i keep changing seems like the lag starts appearing, after around 5 switches in sequence the lag becomes very noticiable. - Adding FizzyFlower Essentials and Concept & Illustration 1.2 bundles, after restarting krita -> Same behavior as before but once it starts lagging the lag is not as much - Adding the files(brush and presets) for both bundles, instead of importing the bundle -> there is a bit of lag sometimes but is greatly reduced. When adding more bundles even the krita 4 bundle starts lagging. Honestly the more I test the more confused I get cause the behavior is inconsistent, sometimes all brush changes lag other times just changing to brushes in the bundles lag. Seems like the bundle files create a bit more lag than having the separate files in the folders. The only thing i could conclude so far is that importing all bundles as preset and brush files seem to work as a workaround up to a certain point, as too many will get to the same slowdown.
hello I also want to report that i have this very exact bug, even to the point of the exact same 3sec delay. It also happens for me when i import large bundles. Removing the resource folder and then letting krita create a new one without added bundles also seems to fix the issue, until i add new large bundles there as well.. The / key also works instantly. Deactivating the bundle also does not fix the lag, i have to completely delete it in order to see any improvements
Same exact problem with Krita 5.0.0 on Windows 10. - Triggered after importing the "Rakurri Brush Set V2" - Picking presets or using the "Reload Original Preset" action gives a big delay. - Switching with the "/" Shortcut has no delay. - Disabling the presets had no effect. - Deleting the database had no effect. - Deleting the bundle fixed the issue, re-importing it brings the issue back.
*** Bug 448226 has been marked as a duplicate of this bug. ***
I thought it would be relevant to post this information here. Seems like checking "Temporarily save tweeks to presets" in the brush editor fixes the problem in 5.0.2. I still hope this can be fixed without needing to have this activated and hopefully this information helps into finding the problem. But seems like a workaround for now. This workaround was discovered in this thread https://krita-artists.org/t/slight-pause-when-switching-brushes/36079
Please test the current nightly stable and unstable builds -- there have been several iterations of performance improvements if there are many resources loaded.
Created attachment 147383 [details] pic I installed a lot of brushes for testing. Some brushes are no longer delayed. But the rest still loads very slowly. Seems to be because of the textures they have.
Tested on Nightly version 5.0.2-alpha-fa949bbef0 with large bundle: "Rakkuri Brushset v2". problem persists: - 3 second freeze when picking different brushes. - checking "Temporarily save tweeks to presets" in the brush editor fixes the problem. Freeze still happens when reloading original preset.
Tested both builds. the problem still persists. The performance improvements do not seem to make any difference in this issue, at least for me. Unlike thetwo report, all brushes cause the delay on selection and there seems to have no relation to brush textures as even selecting basic-1 causes delay. in some cases the delay seems even worse than before, sometimes taking up to 8 seconds and freezing krita. There were also no relevant logs in the log file.
Problem persists in 5.05 (using windows 10 and a pretty powerful PC). When I import smaller bundles it works fine, when I import the 180mb rakurri bundle, there is a 3 second lag everytime I switch a brush. Deactivating the bundle makes no difference one it was imported, I need to manually delete the resources folder.
*** Bug 452872 has been marked as a duplicate of this bug. ***
I was able to confirm that check marking "temporarily save tweaks to presets" corrects the issue.
(In reply to Dziban from comment #20) > I was able to confirm that check marking "temporarily save tweaks to > presets" corrects the issue. Only if you don't "Reload Original Preset". If you do you get the same freeze.
Is this still an issue now that https://bugs.kde.org/show_bug.cgi?id=446146 is fixed?
(In reply to tomtomtomreportingin from comment #22) > Is this still an issue now that https://bugs.kde.org/show_bug.cgi?id=446146 > is fixed? hello, after using the recent nightly builds i can confirm this issue is completely resolved, both reloading presets and changing presets without the save temporary tweeks on have no delay whatsoever. Now, apologies but i dont know if its me that should change the status to resolved or if it should be one of the devs.