Bug 419903

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.