Bug 456197 - Pattern is loaded only after the brush is selected. Default brushes
Summary: Pattern is loaded only after the brush is selected. Default brushes
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Resource Management (show other bugs)
Version: 5.0.6
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-01 09:17 UTC by RamonMiranda
Modified: 2024-10-24 11:36 UTC (History)
1 user (show)

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


Attachments
The patterns in .png to be replaced. They need to be renamed but .pat is what the brush looks for (240.89 KB, image/png)
2022-07-01 09:17 UTC, RamonMiranda
Details
This is for pastel details (80.65 KB, image/png)
2022-07-01 09:18 UTC, RamonMiranda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description RamonMiranda 2022-07-01 09:17:42 UTC
Created attachment 150314 [details]
The patterns in .png to be replaced. They need to be renamed but .pat is what the brush looks for

SUMMARY
Pattern is loaded only after the brush is selected. Default brushes.  
g) Dry Textured Creases   
h) Chalk Details
These brushes are afected and create 2 issues. Lag while loading the texture the first time. And second if i create a variant from them and save it with different name. If i restart Krita and i select the variant first, the texture is not created. Tested from Scratch in Windows 10 and Kubuntu 


STEPS TO REPRODUCE
1. 
2. 
3. 

OBSERVED RESULT
The brushstroke has no texture until i 

EXPECTED RESULT
Those patterns must be created by default. (added in attachment) They are named as .pat Extension maybe is related with that? 
I add the images in png format 

SOFTWARE/OS VERSIONS
Windows: 10
macOS: 
Linux/KDE Plasma: Kubuntu
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 RamonMiranda 2022-07-01 09:18:51 UTC
Created attachment 150315 [details]
This is for pastel details
Comment 2 Dmitry Kazakov 2024-10-24 11:33:09 UTC
Git commit 072460560b704e9ab36f488b35081bf49c7b9edd by Dmitry Kazakov.
Committed on 24/10/2024 at 11:27.
Pushed by dkazakov into branch 'master'.

Fix loading .kpp files with embedded top-level resources

The patch fixes multiple issues with loading embedded (side-loaded) resources
from the .kpp files:

1) Side-loaded resources were **never** loaded (since the very beginning of 5.0),
    because `reader.text("embedded_resources").toInt()` was read from a wrong
    place. The number of resources is stored in XML data, not in the PNG's metadata
    field.

    Now Krita doesn't check the resource count at all and just iterates over the XML to
    find "resource" elements.

2) A new KoResource::sideLoadedResources() method is introduced. It returns a one-time-
    available resources which are loaded alongside the main resource. These side-loaded
    resources can be expelled from memory by calling clearSideLoadedResources(), which
    is called by KisResourceLocator right after loading the resources into the memory.

3) KisResourceLocator now calls loadRequiredResources() in all code paths that load the
    resource into memory (to make sure all its embedded resources are loaded). Previously
    it required a Krita restart to load the embedded resources, cause it happened only during
    the normal lazy-loading.

4) Fixed KisEmbeddedTextureData::loadLinkedPattern() to return FailedLink resource
    instead of invalid EmbeddedResource, when the actual "patternBase64" tag is missing
    (it is missing in 5.0 version of the presets)

5) Adds a unittest that checks all these peculiarities (see KisPaintOpPresetTest)

NOTE:
Bug 456197 is "kind of fixed" with this patch, because side-loaded resources are now
loaded correctly. Though the problem may still be valid for other resource types that
do not side-load the dependencies.
Related: bug 487866, bug 456586

M  +50   -30   libs/image/brushengine/kis_paintop_preset.cpp
M  +3    -0    libs/image/brushengine/kis_paintop_preset.h
M  +1    -0    libs/image/tests/CMakeLists.txt
A  +108  -0    libs/image/tests/KisPaintOpPresetTest.cpp     [License: GPL(v2.0+)]
A  +21   -0    libs/image/tests/KisPaintOpPresetTest.h     [License: GPL(v2.0+)]
A  +-    --    libs/image/tests/data/test-embedded-resources-2.2.kpp
A  +-    --    libs/image/tests/data/test-embedded-resources-5.0.kpp
M  +39   -21   libs/resources/KisResourceLocator.cpp
M  +17   -0    libs/resources/KoResource.cpp
M  +28   -0    libs/resources/KoResource.h
M  +6    -1    plugins/paintops/libpaintop/KisEmbeddedTextureData.cpp

https://invent.kde.org/graphics/krita/-/commit/072460560b704e9ab36f488b35081bf49c7b9edd
Comment 3 Dmitry Kazakov 2024-10-24 11:36:03 UTC
Git commit 869cad0ce67c7786058de47c42909a9dd285597f by Dmitry Kazakov.
Committed on 24/10/2024 at 11:35.
Pushed by dkazakov into branch 'krita/5.2'.

Fix loading .kpp files with embedded top-level resources

The patch fixes multiple issues with loading embedded (side-loaded) resources
from the .kpp files:

1) Side-loaded resources were **never** loaded (since the very beginning of 5.0),
    because `reader.text("embedded_resources").toInt()` was read from a wrong
    place. The number of resources is stored in XML data, not in the PNG's metadata
    field.

    Now Krita doesn't check the resource count at all and just iterates over the XML to
    find "resource" elements.

2) A new KoResource::sideLoadedResources() method is introduced. It returns a one-time-
    available resources which are loaded alongside the main resource. These side-loaded
    resources can be expelled from memory by calling clearSideLoadedResources(), which
    is called by KisResourceLocator right after loading the resources into the memory.

3) KisResourceLocator now calls loadRequiredResources() in all code paths that load the
    resource into memory (to make sure all its embedded resources are loaded). Previously
    it required a Krita restart to load the embedded resources, cause it happened only during
    the normal lazy-loading.

4) Fixed KisEmbeddedTextureData::loadLinkedPattern() to return FailedLink resource
    instead of invalid EmbeddedResource, when the actual "patternBase64" tag is missing
    (it is missing in 5.0 version of the presets)

5) Adds a unittest that checks all these peculiarities (see KisPaintOpPresetTest)

NOTE:
Bug 456197 is "kind of fixed" with this patch, because side-loaded resources are now
loaded correctly. Though the problem may still be valid for other resource types that
do not side-load the dependencies.
Related: bug 487866, bug 456586

M  +50   -30   libs/image/brushengine/kis_paintop_preset.cpp
M  +3    -0    libs/image/brushengine/kis_paintop_preset.h
M  +1    -0    libs/image/tests/CMakeLists.txt
A  +108  -0    libs/image/tests/KisPaintOpPresetTest.cpp     [License: GPL(v2.0+)]
A  +21   -0    libs/image/tests/KisPaintOpPresetTest.h     [License: GPL(v2.0+)]
A  +-    --    libs/image/tests/data/test-embedded-resources-2.2.kpp
A  +-    --    libs/image/tests/data/test-embedded-resources-5.0.kpp
M  +39   -21   libs/resources/KisResourceLocator.cpp
M  +17   -0    libs/resources/KoResource.cpp
M  +28   -0    libs/resources/KoResource.h
M  +6    -1    plugins/paintops/libpaintop/KisEmbeddedTextureData.cpp

https://invent.kde.org/graphics/krita/-/commit/869cad0ce67c7786058de47c42909a9dd285597f