Change Pictures and you will see, that you need time ...
Please describe in more detail what is slow. I definitely don't have a fast computer, but I can't reproduce that the image editor is slow. Most image editing tools have multi core support. Maik
Same here under Windows 10 running in a VM, image editor is very fast... Gilles Caulier
Sorry for less details. I don't know, that the feedback is so great. On the left side of the editor, if you change the images, the program needs over 2 seconds to load the image (3 MB jpg). I see that the image was selected in the main programm too, but though i think the time is to long. I7/SSD 16GB Ram; Fotos on HDD Thanks for comments ... Thomas
Where is stored the database : in local or shared on the local network ? There is a editor version outside digiKam without database support : showfoto. I's installed with digiKam. Can you reproduce the problem ? Another helper is to install DebugView program from Microsoft and to list all digiKam debug trace while you switch from one item to another one. Look here for details : https://www.digikam.org/contribute/ Gilles Caulier
Sorry for less details. I don't know, that the feedback is so great. On the left side of the editor, if you change the images, the program needs over 2 seconds to load the image (3 MB jpg). ... and over 0,5 seconds to mark/select the image, when you click on a image of the left image selection in the editor. I see that the image was selected in the main programm too, but though i think the time is to long. I7/SSD 16GB Ram; Fotos on HDD Thanks for comments ... Thomas
(In reply to caulier.gilles from comment #4) > Where is stored the database : in local or shared on the local network ? > > There is a editor version outside digiKam without database support : > showfoto. I's installed with digiKam. Can you reproduce the problem ? > > Another helper is to install DebugView program from Microsoft and to list > all digiKam debug trace while you switch from one item to another one. > > Look here for details : > > https://www.digikam.org/contribute/ > > Gilles Caulier The database is local, but with type MySQL-Server (experimentell). Perhaps the problem is there ...
Thanks for your answere. In showfoto the time is little bit shorter. In showfoto/image-selection left side, when you change the image with key down or up, it lags ca. 0,5 secs to select next image and ca. 0,5 secs to load the image. Fotos now on SSD.
Another test also is to switch from Mysql to Sqlite database Gilles Caulier
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Thanks in advance Gilles Caulier
Hi Tomas, Hi hans and happy new year, Can you reproduce this problem with digiKam 7.5.0 pre-release available here : https://files.kde.org/digikam/ Best regards Gilles Caulier
@Thomas digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
(In reply to caulier.gilles from comment #11) > @Thomas > > digiKam 8.0.0 is out. This entry still valid with this release ? > > Best regards > > Gilles Caulier I have the same issue using Windows 11, Showfoto 8.0.0, local JPG, 2.6MB, 4000 px x 3000 px takes 1.8s to preview.
Created attachment 159527 [details] procmon log (sysinternals) This is a procmon log of switching preview to a new image. You can see that the same file is opened multiple times (first 200 kB, then complete file, then 200 kB again). Also main read buffer size seems very small (4 kB). However the most time consumption is between the file read accesses. 670 ms consumption between function calls: _ShowFoto::ShowfotoFolderViewSideBar::setCurrentPath(QString const&) _Digikam::EditorCore::load(QString const&, Digikam::IOFileSettings*) 160 ms file i/o read 2.6 mb in 4 kB chunks 670 ms consumption between functions calls: _Digikam::EditorCore::slotImageLoaded(Digikam::LoadingDescription const&, Digikam::DImg const&) _Digikam::LoadingCacheFileWatch::addedImage(QString const&)
@gw@afk74.de, This problem still reproducible with the new digiKam 8.2.0 pre-release Windows installer available at usual place: https://files.kde.org/digikam/ This new bundle is based on last Qt framework 5.15.11 and KDE framework 5.110. Thanks in advance Gilles Caulier
(In reply to caulier.gilles from comment #14) > @gw@afk74.de, > > > This problem still reproducible with the new digiKam 8.2.0 pre-release > Windows > installer available at usual place: > > https://files.kde.org/digikam/ > > This new bundle is based on last Qt framework 5.15.11 and KDE framework > 5.110. > > Thanks in advance > > Gilles Caulier Yes, still reproducible. File is still read in 4kb chunks. Same file takes now 1.9s.
Hi, The 8.7.0 pre-release Windows installer from today have been rebuilt from scratch with Qt 6.8.3, KDE 6.12, OpenCV 4.11 + CUDA support, Exiv2 0.28.5, ExifTool 13.27, ffmpeg 7, all image codecs updated to last version (jxl, avif, heif, aom, etc.). Please try with this version to see if your problem still reproducible... https://files.kde.org/digikam/ Thanks in advance Best regards Gilles Caulier
@gw@afk74.de, We never reproduced the dysfunction. Please give us a feedback with digKam 8.8.0 stable release Gilles Caulier
Created attachment 187774 [details] attachment-2334795-0.html Entschuldige, wurde bereits behoben. Liebe Grüße Thomas Erlacher <bugzilla_noreply@kde.org> schrieb am Do., 18. Dez. 2025, 13:07: > https://bugs.kde.org/show_bug.cgi?id=419903 > > --- Comment #17 from caulier.gilles@gmail.com --- > @gw@afk74.de, > > We never reproduced the dysfunction. Please give us a feedback with digKam > 8.8.0 stable release > > Gilles Caulier > > -- > You are receiving this mail because: > You reported the bug.