Like @Mythmaker said the brush itself doesn’t freeze anything. But it may indeed be confusing to people that it only works some of the time so probably better not to include it in the future.
(If one were to finish a painting in a single session with the lightness layer still not baked - a neat thing you could do with this brush is to separate the lightness effect. Erase, copy, undo, paste. Desaturate and use Arcus Tangent blending mode (on copies or clone layers). You could then add a color tint with a gradient map or adjust the contrast.)
I have fixed two performance issues when loading the V7 bundle and, specifically, “Photo B2” brush preset. Does it look better in this build?
How to test:
Go to %appdata%\Krita folder (or ~/.local/share/krita)
Remove (or move to a safe space the two files):
memileo_360light_07.bundle
resourcecache.sqlite
Start Krita (it will rescan the resources)
Try to import the bundle again → it should happen much quicker
Open the brush selector → it should open much faster
try to activate “Photo B2” preset → it should activate faster (but not extremely fast)
Please take it into account that removing “resourcecache.sqlite” is mandatory, since the buggy and heavy data has been written to the database, making brush selection/activation much slower.
Just tested out on my PC. It is probably around 3x faster importing the brush bundle (counting without a timer, its down from 22 seconds to 6 seconds) and canvas loads in a lot faster (since I have brush presets open with memileo brushes on my workspace it can be observed upon creating a canvas). Some brushes still can get a bit laggy upon clicking (Photo-A and Photo-I to name a few). A lot better overall though, thank you for this fix!
Krita has encountered an internal error:
SAFE ASSERT (krita): "image.format() == QImage::Format_ARGB32" in file /builds/graphics/krita/libs/brush/KisColorfulBrush.cpp, line 69
Please report a bug to developers!
Press Ignore to try to continue.
Press Abort to see developers information (all unsaved data will be lost)
Krita has encountered an internal error:
SAFE ASSERT (krita): "data" in file /builds/graphics/krita/plugins/paintops/libpaintop/kis_brush_option_widget.cpp, line 111
Please report a bug to developers!
Press Ignore to try to continue.
Press Abort to see developers information (all unsaved data will be lost)
Debug messages for missing resources? (Same messages appear in terminal with 5.2.2 after removing resource cache.)
Import bundle:
MR version - ca 8s
5.2.2 - ca 35s
Selecting PHOTO B 2 for the first time after Krita startup
MR version - ca 1-3s
5.2.2 - ca 4s
or pretty much instant if started with a rgba brush selected and painted with on previous run for both versions.
And also Krita starts so much faster than I’m used to on second run. (15-20s compared to about 1min25s in 5.2.2) Cheers!
This is a new system isn´t it? i remember @dkazakov was using DKX where X is a number.
I need help for testing or do you have enough feedback @dkazakov and @emilm ?
At least if I’m not mistaken.
After @emilm’s hint, I searched again and corrected the links above.
The new system is not so simple as the former was, sorry.
Theoretically, we could improve speed even further by not embedding the brush tips into the presets, when they are saved in bundles, but it will need a bit of quite dangerous redesign, so it cannot be done in 5.2 branch anyway.
The main reason for the slowdown is the usage of piped GBR brushes with about 600 embedded brushes. The problem is that GBR format is not compressed by specification, hence, when we embed that into a .kpp preset, it takes too much time to compress/uncompress it.
The temporary workarounds would be:
Decrease the number of embedded GBR brushes (I’m not sure if it is a good idea)
Manually strip embedded resources from the brush preset. It will have the following consequences though:
you will not be able to manually extract this .kpp preset from the bundle’s zip file without breaking the preset (I’m not sure anyone actually cares about that)
When editing an existing preset it may skip the linked resources. I don’t actually know why this code exists there, but it may cause an issue.
PS:
I can try making a testing and really hackish version of Krita that would skip saving the linked resources based on an environment variable. It will not handle issues gracefully though, so one would have to test the bundles before publishing manually.
If one makes a tweak and saves as a new brush preset, would they then get embedded again?
Do you think these workarounds would also get rid of the occasional freezes/hiccups when painting with these heavy brush tips?
Otherwise is there a certain .gih file size or number of brush images one should aim to keep under when creating an animated brush tip?
The loading definitely seemed faster on the test build (on linux). The main issue I’m having is these brushes are quickly saturating the available memory. That seems to happen on both the stable and test builds.
When I first tested them a couple of days ago, I started painting and all seemed to be working well - the strokes laid out smoothly with decent performance. Then my system suddenly ground to a halt; not like a crash, but effectively frozen. I ended up doing a hard reset to get out of it.
Later I tried again with the system monitor open. I found that ram use jumped with each stroke until it was completely saturated, then spilled over into swap and saturated that - which locked up my system again.
I should note though - My system is pretty old now and only 8gb ram so I had limited scope to observe the rise before it maxed out.
I don’t think it’s the presets or the file size of the brushes; I tested my own largest brush which is also a .gih with lightness, and very large at 42mb in size. I didn’t see the same incremental rise in memory use. That brush only has about 5 or 6 instances though; So I’m wondering if it’s related to the number of layers in the tube?
Do you think these workarounds would also get rid of the occasional freezes/hiccups when painting with these heavy brush tips?
I can make you a test build with instructions how to check that if you promize not to publish the resulting bundle anywhere (otherwise we’ll have to support this king of “broken” bundles officially)
I did a few different tests to try and narrow things down, but I specifically tested that brush with one of emilm’s presets; I didn’t see an incremental rise in memory use when I used that combination, even though it’s a similarly huge file size and the same format.
