[Digikam-devel] [digikam] [Bug 322789] Enabling "color managed view" in editor slows down tool startup

[Peter Albrecht]

https://bugs.kde.org/show_bug.cgi?id=322789

--- Comment #24 from Peter Albrecht <px79 at crazymonkeys.de> ---
In sequence to comment #23:
On the call stack from "ImageRegionWidget::paintPreview()" to
"IccTransform::apply()", in "EditorCore::convertToPixmap()" you can find a
fresh reinitialisation of IccManager and IccTransform.

This may be the reason for those many syscalls of
  open("/usr/share/apps/libkdcraw/profiles/srgb-d65.icm", O_RDONLY|O_CLOEXEC) =
65
in the strace snipped of comment #16.

Those many reinitialisation look bad, but according to my valgrind/callgrind
dump (see  attachment #84472) (very nice to look at with KCachegrind) relative
cost of "IccManager::displayTransform()" is 0.00% (391.390 of 74.381.518.896).
The total cost is the process from "opening the tool Brightness/Contrast/Gamma"
to "tool ready to be used".

The main consumer according to the valgrind-dump is lcms'
"cmsReverseToneCurveEx()", which eats up 76.62%!

So one important question comes to my mind: What does this function do? 
A) Is this part of the initialisation process of lcms? (performance loss, cause
of tiling)
B) Or is it part of the pixel-crunching, which processes my image pixels? (no
effect, cause of tiling)
In case of question A == Yes, the amount of 70 lcms initialisations per
Paint-Event would be fatal!

The API (http://www.littlecms.com/LittleCMS2.5%20API.pdf) I found, reads like A
== Yes. 

But I know almost nothing about color management and lcms. So please, Gilles,
redirect this question to one of digikam's colormanagement experts.

-- 
You are receiving this mail because:
You are the assignee for the bug.