Bug 493437 - Krita briefly freezes when selecting brush presets for the first time
Summary: Krita briefly freezes when selecting brush presets for the first time
Status: CONFIRMED
Alias: None
Product: krita
Classification: Applications
Component: * Unknown (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Compiled Sources All
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-21 13:06 UTC by acc4commissions
Modified: 2024-11-12 21:30 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description acc4commissions 2024-09-21 13:06:35 UTC
Reproducible in the current krita next builds (tested in krita-x64-5.3.0-prealpha-724eeaa9)
It doesn't happen in the krita plus builds


SUMMARY
Krita briefly freezes when selecting brush presets for the first time (In the toolbar)
I have memileo brushes and other heavy brushes in the tag that I'm opening

STEPS TO REPRODUCE
1. Open krita and a document
2. Select brush preset
3. Krita briefly freezes

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 acc4commissions 2024-10-05 13:33:08 UTC
Oddly, it happens in 5.2.6 too.
Comment 2 Dmitry Kazakov 2024-10-25 11:09:05 UTC
I can confirm the issue. The problem happens with these brush presets: https://krita-artists.org/t/memileo-impasto-brushes/92952

The reason:

The presets have a huge texture and a huge brush in the PNG's metadata area saved as base64+XML. So, every time we load the resource (even when this resource is already present in the database), Krita has to:

1) Decompress the metadata block with "inflate" algorithm. It basically, decompresses a chunk that is already compressed and base64 encoded.
2) Iterate through this XML document with huge CDATA sections.

We have multiple solutions for the problem:

1) Just don't save "embedded resources" within the preset, when the preset is saved into a bundle (since bundle also includes them when saving)

2) Save the embedded resources in a separate PNG-metadata section
    * the main "preset" section should still contain the metadata of the embedded resources, but shouldn't contain the CDATA section.
    * the CDATA sections should be stored in a separate PNG-metadata section that is loaded only when needed

3) Do not use QImageBuilder and use libpng directly to disable compression on that extra PNG-metadata section (sounds a bit too much)
Comment 3 Emmet O'Neill 2024-11-12 21:30:44 UTC
> 2) Save the embedded resources in a separate PNG-metadata section
>     * the main "preset" section should still contain the metadata of the embedded resources, but shouldn't contain the CDATA section.
>     * the CDATA sections should be stored in a separate PNG-metadata section that is loaded only when needed

To expand on this idea, maybe we could store a much smaller version of the embedded textures with the preset, which can be loaded quickly, only to swap over to the full-size larger texture after it finishes loading the background. 

Kind of like the mipmap / level-of-detail system that modern game engines use to speed up asset load times.