Created attachment 150734 [details] Full backtrace, see thread 11 1) Open a very huge PSD file, e.g. the one from bug 444844. The file should be so huge that it opens about a minute. 2) Close the document and Krita 3) Open Krita 4) Make sure that the huge file in the "recent documents" list 5) Close Krita 6) [BUG] See that Krita stays in the task manager for a few minutes until it generates a thumbnail for that huge "recent document"
Erm, according to the stacktrace, this should go into frameworks-kimageformats.
Erm, KisRecentFileIconCache belongs to Krita and it is the one who waits for the completion of the background thread.
Git commit 48ca610ae89be95eb1db477379e54b37ab478ec2 by Dmitry Kazakov. Committed on 19/07/2022 at 13:04. Pushed by dkazakov into branch 'master'. Use Krita's engine to load previews for PSD files It makes loading of preview for the complex file from bug 444844 reduce from 300 sec to 40 sec. M +4 -1 libs/ui/utils/KisFileIconCreator.cpp https://invent.kde.org/graphics/krita/commit/48ca610ae89be95eb1db477379e54b37ab478ec2
Git commit 759e0ad68560bf775b4a4730b9be701a2a51f45e by Dmitry Kazakov. Committed on 19/07/2022 at 13:04. Pushed by dkazakov into branch 'krita/5.1'. Use Krita's engine to load previews for PSD files It makes loading of preview for the complex file from bug 444844 reduce from 300 sec to 40 sec. M +4 -1 libs/ui/utils/KisFileIconCreator.cpp https://invent.kde.org/graphics/krita/commit/759e0ad68560bf775b4a4730b9be701a2a51f45e
(In reply to Dmitry Kazakov from comment #2) > Erm, KisRecentFileIconCache belongs to Krita and it is the one who waits for > the completion of the background thread. No. The stacktrace shows the thumbnail creator is executing *Frameworks* code: > #8 (anonymous namespace)::readPixel () at C:/Packaging/KritaDepsBuild/ext_frameworks/ext_kimageformats-prefix/src/ext_kimageformats/src/imageformats/psd.cpp:121 > No locals. > #9 (anonymous namespace)::LoadPSD () at C:/Packaging/KritaDepsBuild/ext_frameworks/ext_kimageformats-prefix/src/ext_kimageformats/src/imageformats/psd.cpp:210 > No locals. > #10 PSDHandler::read () at C:/Packaging/KritaDepsBuild/ext_frameworks/ext_kimageformats-prefix/src/ext_kimageformats/src/imageformats/psd.cpp:259 > No locals. > #11 0x00007ffe99fbc932 in QImageReader::read () at C:\Packaging\KritaDepsBuild\ext_qt\s\qtbase\src\gui\image/qimagereader.cpp:1261 > No locals. > #12 0x00007ffe99fbc6f5 in QImageReader::read () at C:\Packaging\KritaDepsBuild\ext_qt\s\qtbase\src\gui\image/qimagereader.cpp:1202 > No locals. > #13 0x00007ffe99f9ff46 in QImage::load () at C:\Packaging\KritaDepsBuild\ext_qt\s\qtbase\src\gui\image/qimage.cpp:3586 > No locals. > #14 0x00007ffe7d967b4d in KisFileIconCreator::createFileIcon (this=<optimized out>, path=..., icon=..., devicePixelRatioF=<optimized out>, iconSize=...) at C:/dev/env-11/krita/libs/ui/utils/KisFileIconCreator.cpp:133 This is still a bug in Frameworks, and what the associated commit did was work around it. It should be reported upstream so that every downstream user benefits.
(In reply to amyspark from comment #5) > No. The stacktrace shows the thumbnail creator is executing *Frameworks* > code: > > #8 (anonymous namespace)::readPixel () at C:/Packaging/KritaDepsBuild/ext_frameworks/ext_kimageformats-prefix/src/ext_kimageformats/src/imageformats/psd.cpp:121 > > No locals. The PSD read plugin of KImageFormats was rewritten to be faster and more reliable. The slow readPixel() function was removed in April, 2022. The current version of the plugin refuse to load the image of bug 444844 because it seems corrupted somewhere.
I'll try to update our kimageformats package to the latest version -- we cannot simply update every framework to the latest release, because they need Qt 5.15, which is too buggy to use on Windows for us....
Okay, the updated kimageformats psd loader needs QColorSpace (for totally valid reasons), so, we have basically three options: * accept the slowdown and keep using kimageformats 5.64 * move to the KDE fork of Qt 5.15 and fix the issues that has (broken opengl in qmdwindow) -- if those haven't been fixed in the meantime * fix our psd loader to use resources in threadsafe way
5.15 TEST Is this still a problem? I cannot reproduce this on 5.1.5 and even less in Version: 5.2.0-prealpha (git c96fb96), thumbnail generation is relatively faster on master.
The file in question loads in 1200ms now, so I think it should be fine to consider the bug as closed.