[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 #36 from Peter Albrecht <px79 at crazymonkeys.de> ---
(In reply to comment #34)
> I suspect something wrong with widget style which send a lots of signal to widget at init (i don't know why).
> ...
> Just to be sure, change your KDE widget style. Go to digiKam setup misc.
> Here i use Oxygen widget.

Gilles, you are right! I use widget style "QtCurve" (gentoo ebuilds:
x11-themes/gtk-engines-qtcurve-1.8.16 and x11-themes/qtcurve-1.8.14). And there
is definitely a problem with this style and digikam: It adds one redundant call
to PreviewWidget::viewportPaintEvent() to the "editor tool opening" process!

Using digikam with "Oxygen" widget style, PreviewWidget::viewportPaintEvent()
is called ONCE, while editor tool is beeing opened.
Using digikam with "QtCurve" widget style, PreviewWidget::viewportPaintEvent()
is called TWICE, while editor tool is beeing opened.

But there is also another, more important bug in
PreviewWidget::viewportPaintEvent() and its called functions: See 
> d->handle is always "0x0"
in comment #33.

This "viewportPaintEvent()" bug makes me wait 6 seconds for one call to
PreviewWidget::viewportPaintEvent().

So fixing the "QtCurve widget bug" will reduce my waiting time from 12 to 6
seconds, while fixing the "viewportPaintEvent() bug" will reduce waiting time
to 1 second. That's the time the editor needs to process its
Canvas::viewportPaintEvent(), so I guess viewportPaintEvent() can get as fast
as that, if d->handle is not always "0x0".

So I'll concentrate on viewportPaintEvent() first. Also the "QtCurve widget
bug" seems to be more complicated to solve, since you need good KDE knowledge,
which I don't have (yet ;).
Should I open a separate bug: "QtCurve widget: calling
PreviewWidget::viewportPaintEvent() twice on editor tool opening"  ?

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