Bug 447298 - Closing documents takes significantly longer than before
Summary: Closing documents takes significantly longer than before
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Unclassified
Component: General (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2021-12-20 17:14 UTC by tomtomtomreportingin
Modified: 2022-06-17 13:36 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.