Bug 443629

Summary: Heavy lags in brushes with patterns in beta2
Product: [Applications] krita Reporter: anno2300
Component: Brush enginesAssignee: Dmitry Kazakov <dimula73>
Status: RESOLVED FIXED    
Severity: normal CC: halla, tamtamy.tymona
Priority: NOR Keywords: regression, release_blocker
Version: 5.0.0-beta2   
Target Milestone: ---   
Platform: Other   
OS: macOS   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: attachment-26203-0.html

Description anno2300 2021-10-12 08:40:03 UTC
SUMMARY
I have heavy, really heavy brush lags in some brushes, in every stroke. It looks like i paint and then the brushstroke is applied in a delay of a half of a second. It is in every brushstroke and not just in the fist stroke of a brush. At the moment it looks like this happens in brushes with patterns that aren't showed correctly in the library and you have to reselect it, then the lag is away.

STEPS TO REPRODUCE
1. As a sample aktivate the brush: y) Texture Reptile
2. Paint
3. See that every stroke is painted with a delay

For the Default Resouces, there is also the y) Texture Wood Fibre and for
Digital Atelier: DA Pastel 02 Wibbly lines. Idk if there are more brushes with lags too.


SOFTWARE/OS VERSIONS
macOS Big Sur 11.6
Comment 1 Dmitry Kazakov 2021-10-13 10:15:06 UTC
I can reproduce that in both, master and krita/5.0 branch
Comment 2 Dmitry Kazakov 2021-10-13 10:47:34 UTC
The whole delay time is spent in KisResourceThumbnailPainter::getReadyThumbnail(), which is crazy... :(
Comment 3 Dmitry Kazakov 2021-10-13 10:53:57 UTC
No, I'm wrong. The preview delay happens every time one switches back to Krita window (or select a preset that causes scrollinf in the preset selection docker)
Comment 4 Halla Rempt 2021-10-13 11:28:14 UTC
DId we forget to fix/revert this?


commit 00c6a08397a78c04f11b46b3e4a4c4e24b3636c9
Author: Scott Petrovic <scottpetrovic@gmail.com>
Date:   Fri Sep 17 11:02:38 2021 -0500

    refactor thumbnail code so it shared thumbnail generation
Comment 5 Wojciech Kosowicz 2021-10-13 11:46:03 UTC
Created attachment 142392 [details]
attachment-26203-0.html

śr., 13 paź 2021, 13:28 użytkownik Halla Rempt <bugzilla_noreply@kde.org>
napisał:

> https://bugs.kde.org/show_bug.cgi?id=443629
>
> --- Comment #4 from Halla Rempt <halla@valdyas.org> ---
> DId we forget to fix/revert this?
>
>
> commit 00c6a08397a78c04f11b46b3e4a4c4e24b3636c9
> Author: Scott Petrovic <scottpetrovic@gmail.com>
> Date:   Fri Sep 17 11:02:38 2021 -0500
>
>     refactor thumbnail code so it shared thumbnail generation
>
> --
> You are receiving this mail because:
> You are watching all bug changes.
>
>
Comment 6 Dmitry Kazakov 2021-10-13 12:46:37 UTC
Okay, the real problem is in how we calculate MD5 of the pattern. The MD5 of the pattern doesn't coincide with the one written in the preset, so it loads embedded pattern all the time, even when there is a copy in the resource server.
Comment 7 Bug Janitor Service 2021-10-15 06:41:31 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1098
Comment 8 Dmitry Kazakov 2021-10-15 09:25:41 UTC
Git commit 23e4917f5a0fe0b28a277d33468948a9ac34665d by Dmitry Kazakov.
Committed on 15/10/2021 at 06:31.
Pushed by rempt into branch 'master'.

Fix loading of textures in presets with invalid MD5 tag

Some of our presets have invalid MD5 tag saved for the textures. It
could happen due to the fact that they used resource->md5() when saving,
but saveToDevice() changed the actual MD5.

This patch is the first stage of the proposal in this task:

Ref https://phabricator.kde.org/T14946

M  +34   -13   libs/resources/KisResourcesInterface.cpp

https://invent.kde.org/graphics/krita/commit/23e4917f5a0fe0b28a277d33468948a9ac34665d
Comment 9 Dmitry Kazakov 2021-11-13 11:18:28 UTC
Git commit 2734bc3eb81b11f5c7cbffbd7a78dd9289bde717 by Dmitry Kazakov.
Committed on 13/11/2021 at 09:30.
Pushed by dkazakov into branch 'krita/5.0'.

Fix loading of textures in presets with invalid MD5 tag

Some of our presets have invalid MD5 tag saved for the textures. It
could happen due to the fact that they used resource->md5() when saving,
but saveToDevice() changed the actual MD5.

This patch is the first stage of the proposal in this task:

Ref https://phabricator.kde.org/T14946

M  +34   -13   libs/resources/KisResourcesInterface.cpp

https://invent.kde.org/graphics/krita/commit/2734bc3eb81b11f5c7cbffbd7a78dd9289bde717