Bug 447298

Summary:	Closing documents takes significantly longer than before
Product:	[Applications] krita	Reporter:	tomtomtomreportingin
Component:	General	Assignee:	Dmitry Kazakov <dimula73>
Status:	RESOLVED FIXED
Severity:	normal	CC:	dimula73, griffinvalley
Priority:	NOR	Keywords:	regression
Version:	nightly build (please specify the git hash!)
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:

Description tomtomtomreportingin 2021-12-20 17:14:48 UTC

5.0 git 50f8936

SUMMARY
Closing (and opening?) documents takes significantly longer than before, representing a small freeze before proceeding to other operations.

STEPS TO REPRODUCE
1. Open a document.
2. Close the document.
3. Right after step 2, click the News menu button or click a recent document.

OBSERVED RESULT
The welcome screen is frozen for at least a couple seconds.

EXPECTED RESULT
There should no perceivable performance difference between 5.0 beta 2 and 5.0 git 50f8936.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian sid
KDE Plasma Version: 5.23.3
KDE Frameworks Version: 5.88.0
Qt Version: 5.12.11 (appimage)

Comment 1 tomtomtomreportingin 2021-12-20 17:17:39 UTC

Since such lag was not perceivable in beta 2, this is a regression.

Comment 2 wolthera 2021-12-20 17:45:21 UTC

I can only reproduce when there's been two or more images opened in a given session, a single image behaves normally. Opening times is equal between both krita-5.0.0-beta2-5771a7d-x86_64.appimage and krita-5.0.0-x86_64.appimage .

This leads me to believe that the problem lies in image handling. There's been several bug fixes there, between

https://invent.kde.org/graphics/krita/-/commit/451e1415fd1b3a0f9c24de2fd4707d1b1e164236
and
https://invent.kde.org/graphics/krita/-/commit/a9fc8fa7b270871996924e19ba7456cccab452b5

As most of these commits fix crashes, I do not think we should revert these, and I do not consider this a release blocker.

Comment 3 Dmitry Kazakov 2021-12-21 08:41:48 UTC

Yeah, the problem happens because the destructor of the document tries to deregister the temporary storages, this deregistration takes 900ms with the default set of bundles.

Comment 4 Bug Janitor Service 2021-12-21 12:23:58 UTC

A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1253

Comment 5 Dmitry Kazakov 2022-01-05 08:35:08 UTC

Git commit b086633b58c0279ffe2da97e00dc779f04a24905 by Dmitry Kazakov.
Committed on 05/01/2022 at 08:34.
Pushed by dkazakov into branch 'master'.

Fix delay when opening and closing a document

Basically, we shouldn't reset all the models when we add/remove a
storage, we have all the information necessary for a graceful update.
Document creation/closing time drops from 900ms to 300ms.

Limitations of the patch:

* it fixes only the case when the user has no tag selected

Still TODO:

* implement the same updates for KisAllTagResourceModel
* implement proper updates for the case when we disable/enable a source,
  right now it causes full reset as well

M  +34   -0    libs/resources/KisResourceCacheDb.cpp
M  +1    -0    libs/resources/KisResourceCacheDb.h
M  +46   -5    libs/resources/KisResourceLocator.cpp
M  +3    -3    libs/resources/KisResourceLocator.h
M  +16   -14   libs/resources/KisResourceModel.cpp
M  +4    -4    libs/resources/KisResourceModel.h
M  +1    -1    libs/resources/KisTagResourceModel.cpp

https://invent.kde.org/graphics/krita/commit/b086633b58c0279ffe2da97e00dc779f04a24905

Comment 6 Dmitry Kazakov 2022-01-05 08:37:45 UTC

Git commit a211005a8714429c14b7627a2803ce25daec52fa by Dmitry Kazakov.
Committed on 05/01/2022 at 08:35.
Pushed by dkazakov into branch 'krita/5.0'.

Fix delay when opening and closing a document

Basically, we shouldn't reset all the models when we add/remove a
storage, we have all the information necessary for a graceful update.
Document creation/closing time drops from 900ms to 300ms.

Limitations of the patch:

* it fixes only the case when the user has no tag selected

Still TODO:

* implement the same updates for KisAllTagResourceModel
* implement proper updates for the case when we disable/enable a source,
  right now it causes full reset as well
(cherry picked from commit b086633b58c0279ffe2da97e00dc779f04a24905)

M  +34   -0    libs/resources/KisResourceCacheDb.cpp
M  +1    -0    libs/resources/KisResourceCacheDb.h
M  +46   -5    libs/resources/KisResourceLocator.cpp
M  +3    -3    libs/resources/KisResourceLocator.h
M  +16   -14   libs/resources/KisResourceModel.cpp
M  +4    -4    libs/resources/KisResourceModel.h
M  +1    -1    libs/resources/KisTagResourceModel.cpp

https://invent.kde.org/graphics/krita/commit/a211005a8714429c14b7627a2803ce25daec52fa

Comment 7 Dmitry Kazakov 2022-01-05 08:39:43 UTC

Git commit 263cd91b3e28b75b702b3aaa28f91a69ec217ba4 by Dmitry Kazakov.
Committed on 05/01/2022 at 08:38.
Pushed by dkazakov into branch 'krita/5.0.0'.

Fix delay when opening and closing a document

Basically, we shouldn't reset all the models when we add/remove a
storage, we have all the information necessary for a graceful update.
Document creation/closing time drops from 900ms to 300ms.

Limitations of the patch:

* it fixes only the case when the user has no tag selected

Still TODO:

* implement the same updates for KisAllTagResourceModel
* implement proper updates for the case when we disable/enable a source,
  right now it causes full reset as well
(cherry picked from commit b086633b58c0279ffe2da97e00dc779f04a24905)

M  +34   -0    libs/resources/KisResourceCacheDb.cpp
M  +1    -0    libs/resources/KisResourceCacheDb.h
M  +46   -5    libs/resources/KisResourceLocator.cpp
M  +3    -3    libs/resources/KisResourceLocator.h
M  +16   -14   libs/resources/KisResourceModel.cpp
M  +4    -4    libs/resources/KisResourceModel.h
M  +1    -1    libs/resources/KisTagResourceModel.cpp

https://invent.kde.org/graphics/krita/commit/263cd91b3e28b75b702b3aaa28f91a69ec217ba4

Comment 8 Dmitry Kazakov 2022-06-17 13:36:31 UTC

I think this bug can now be closed as resolved, since the document is now closed in a fraction of a blink. There is still a small delay (about 300ms) on deactivation/activation of bundles, but that is a different bug.