I have been using digiKam with a color managed workflow since January 2013. This worked well with digiKam 2.9.0 and digiKam 3.1.0. They both depend on lcms 1.x (slot 0). (portage picked 1.19 for me) In July 2013 I switched to digiKam 3.2.0, which depends on lcms slot 2. (portage picked version 2.3 and later 2.5) Since this, the following problem appeared: Starting tools like "Brightness/Contrast/Gamma…" in digiKam's Image Editor takes 12 seconds until the tool can be used. I have also reported this bug at digiKam's bug-tracker: https://bugs.kde.org/show_bug.cgi?id=322789 Tested facts: 1) disabling "Color.Mananged View" in digiKam makes the tool start in 2 seconds (expected behaviour) 2) switching back to digiKam 3.1.0 (with lcms 1.19) makes the tool start in 2 seconds (expected behaviour) 3) creating a new linux user with a fresh, new KDE profile and digiKam config, did not solve the problem 4) Gilles Caulier, one of digiKam's lead developers, could not reproduce the problem with his linux distribution (not gentoo linux) => may a gentoo problem 5) using Gilles' ICC-file did not solve the problem, so it is not an broken ICC-profile 6) the time to wait, depends heavily on the size of the Image Editor window: smalest possible window-size => waiting time 3 seconds; largest possible window size => waiting time of 12 seconds 7) Image Editor itself opens up in 1 seconds and displays the image in color managed view, so digiKam's use of lcms works well in some cases. Environment: - KDE 4.11.2 (at the moment, but problems also existed with 4.10.4 and 4.10.5-r1) - last "emerge -uND world" 21. Dec 2013 - first line of emerge --info: Portage 2.2.7 (default/linux/amd64/13.0/desktop/kde, gcc-4.6.3, glibc-2.16.0, 3.10.17-gentoo x86_64) Reproducible: Always Steps to Reproduce: 1. emerge media-gfx/digikam-3.5.0 media-gfx/dispcalgui 2. install a color managed workflow: (I used: http://scribblesandsnaps.com/2013/01/22/calibrate-and-profile-monitor-for-use-with-digikam/) 2.1. start dispcalGUI 2.2. download ICC file: https://bugs.kde.org/attachment.cgi?id=81425 2.3. under "Options" pick "Install display device profile..." 2.4. select the downloaded ICC profile and install for current user 3. start digiKam 4. in digiKam settings enable "Color Management" (make shure to check "Use colormanaged view in editor" on the "Profiles" tab) 5. open an image in digiKam's Image Editor ("Image" -> "Edit") 6. start editing tool: "Color" -> "Brightness/Contrast/Gamma…" Actual Results: Takes long time (12 seconds on my machine: Intel(R) Core(TM)2 Duo CPU E8400@3.00GHz) until the tool is ready to be used. Expected Results: Tool should be ready to be used in 2 seconds. As it used to be with digiKam 3.1.0 build against lcms 1.19. Has anybody else encountered this problem? What could I do next, find this bug?
No idea yet, I can't reproduce the problem... Is media-libs/lcms-1* still installed on your system? If yes, could you please remove it? emerge -ac media-libs/lcms:0 emerge @preserved-rebuild Does that help? If you can't unmerge lcms:0, what is still pulling it in?
Additional debugging idea, emerge dev-util/strace and then do the following: 1) make sure a clock with seconds display is visible on your screen (e.g., kde bar) 2) in a terminal window start digikam with strace -tt digikam &> digikam-strace.log (note, because of the logging digikam will be slower in any case) 3) note exact time, start one of the "unusually slow tasks" 4) close digikam then take the log file (which will be HUGE) and shorten it so only the parts around that particular time are there, compress it and upload it (warning: it will contain things like file names and file paths...) maybe we can see something from the log
(In reply to Andreas K. Hüttel from comment #1) > Is media-libs/lcms-1* still installed on your system? If yes, could you > please remove it? > emerge -ac media-libs/lcms:0 > emerge @preserved-rebuild > Does that help? > > If you can't unmerge lcms:0, what is still pulling it in? _Short_: Did not help. _Long_: Yes, media-libs/lcms-1.19 was still installed on my system. I removed it the following way: 1) change use-flags of some programms to "-lcms" (e.g. gimp) 2) emerge --update --newuse --deep world 3) emerge -va @preserved-rebuild 4) emerge -C media-gfx/inkscape-0.48.4 5) emerge --depclean (removed lcms-1.19) 6) revdep-rebuild 7) dispatch-conf Now "eix media-libs/lcms" tells me, "2.5-r1(2)" is the only installed version of lcms. I rebuild digiKam and restarted the system. But the initial bug (long waiting time) is still present.
Created attachment 366330 [details] compressed strace log file, see comment #2
(In reply to Andreas K. Hüttel from comment #2) > Additional debugging idea, emerge dev-util/strace and then do the following: > [...] > 2) in a terminal window start digikam with > strace -tt digikam &> digikam-strace.log > (note, because of the logging digikam will be slower in any case) Andreas, this was a very good idea! I created the strace log file, as described and uploaded it to this bug. Very interesting is the fact that you can find 464 times the following lines: ------------------------------------- 8< ------------------------------------- open("/usr/share/apps/libkdcraw/profiles/srgb-d65.icm", O_RDONLY|O_CLOEXEC) = 65 fcntl(65, F_SETFD, FD_CLOEXEC) = 0 fstat(65, {st_mode=S_IFREG|0644, st_size=6924, ...}) = 0 fstat(65, {st_mode=S_IFREG|0644, st_size=6924, ...}) = 0 fstat(65, {st_mode=S_IFREG|0644, st_size=6924, ...}) = 0 read(65, "\0\0\33\flcms\0020\0\0mntrRGB XYZ \7\324\0\10\0\r\0\f"..., 16384) = 6924 read(65, "", 9460) = 0 close(65) = 0 ------------------------------------- >8 ------------------------------------- DigiKam seems to read this profile file 464 times. 6924 is the exact size in bytes of this file on my harddisc. But why does digiKam read this file so often?
(In reply to Peter Albrecht from comment #5) > DigiKam seems to read this profile file 464 times. 6924 is the exact size in > bytes of this file on my harddisc. But why does digiKam read this file so > often? Yeah I've seen that too... no idea why, but we can ask Gilles, maybe he has an idea. As a doublecheck you could rename that file as root and see what happens. (Possibly some error though.)
I just tested this bug with digiKam 4.2.0 and it seems to have been fixed. :) https://bugs.kde.org/show_bug.cgi?id=322789#c41
(In reply to Peter Albrecht from comment #7) > I just tested this bug with digiKam 4.2.0 and it seems to have been fixed. :) > > https://bugs.kde.org/show_bug.cgi?id=322789#c41 Thanks.
