Version: 2.0.0 (using Devel) OS: Linux I'm not sure this is really bound to demosaicing, it might as well be a general GUI issue. If I open a RAW image in the image editor the demosaicing sidebar opens with the post-processing tab active. That pane has two histograms which need calculating i.e. they do not show up but have a turning circle which signals that there is work in progress. Other than that there is only the progress bar in the status bar at the bottom-left which moves. These two elements or some non-visible task make Xorg consume 30% CPU and hence slows down digikam's demosaicing. The cpu usage starts when the demosaicing starts and stops as soon as the picture is displayed. Disabling desktop effects does not help, so I do not think it is related to some effect. Or is Xorg used to demosaic? Reproducible: Always Steps to Reproduce: Open the process list and sort for CPU usage Set digikam to open the demosaicing tool when opening a RAW picture in the image editor Open a RAW picture in the image editor Actual Results: Xorg consumes 30% CPU while demosaicing Expected Results: Only digikam should consume cpu while demosaicing.
I guess you compile from source. Go to libs/dimg/levels/histogramwidget.cpp, method slotProgressTimerDone (line 496) and add "return;" as first statement in that method. Recompile and check again, this time without the progress indicator. If CPU load is gone now: - the Linux graphics stack needs to be fixed (Qt5, Wayland, Gallium) - we should use update() instead of repaint()
With the histogram's turning circle stopped and only the same turning circle of the luminosity curve moving Xorg is down to ~6% CPU usage. So maybe disabling the turning for the luminosity curve improves things further. Since they do not indicate any progress anyway, i.e. no percentage they might as well be replaced with a static text "please wait while loading" or something like that. And digikam could brag about having enhanced demosaicing speed by 30%. :)
I will not change anything substantial in digikam because the Linux graphics stack is so much broken with certain driver/X.org combinations that drawing a 32px pixmap needs 30% of a modern CPU. I am currently updating parts of the HistogramWidget, removing the use of repaint(), using an animation so that at least on our end we do everything as we should.
Git commit 8edb81662a6727f1d6a2c76ce006d0d990fcb2e9 by Marcel Wiesweg. Committed on 17/07/2011 at 16:35. Pushed by mwiesweg into branch 'master'. Remove all calls to repaint(), use update(). Remove self-made timer, use QAnimation framework. Remove a lot of code duplication. BUG: 277927 M +12 -8 libs/dimg/filters/levels/histogramwidget.h M +5 -2 libs/dimg/filters/levels/imagehistogram.h M +6 -6 libs/dimg/filters/curves/curveswidget.cpp M +223 -283 libs/dimg/filters/levels/histogramwidget.cpp M +2 -2 libs/dimg/filters/curves/curveswidget.h M +6 -5 libs/dimg/filters/levels/imagehistogram.cpp http://commits.kde.org/digikam/8edb81662a6727f1d6a2c76ce006d0d990fcb2e9