svn version memory usage

[D Bera]

Hi
        Ever since I started using digikam-0.9 (built from svn checkout) I observed
digikam has became quite slow. Simple opening the images or changing contrast
etc. is taking quite a long time compared to digikam-0.8.x. Curious, I
checked the memory usage of digikam.

RES is 99MB
(VIRT is 152 MB)
Only 22 MB shared. 99MB RES is a huge amount. I never checked memory usage in
0.8 (it was quite snappy and quick) but I am sure it wasnt this huge. Has
anything changed significantly in digikam-0.9 to cause this behaviour ?
I am running the svn copy as of 7-days old.
I can provide details of memory usage using exmap if required or do some
testing if required.

- dBera

--
-----------------------------------------------------
Debajyoti Bera @ http://dtecht.blogspot.com
beagle / KDE fan
Mandriva / Inspiron-1100 user
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-2]

On Monday 25 September 2006 16:32, Debajyoti Bera wrote:

> Hi
> Ever since I started using digikam-0.9 (built from svn checkout) I
> observed digikam has became quite slow. Simple opening the images or
> changing contrast etc. is taking quite a long time compared to
> digikam-0.8.x. Curious, I checked the memory usage of digikam.
>
> RES is 99MB
> (VIRT is 152 MB)
> Only 22 MB shared. 99MB RES is a huge amount. I never checked memory usage
> in 0.8 (it was quite snappy and quick) but I am sure it wasnt this huge.
> Has anything changed significantly in digikam-0.9 to cause this behaviour ?
> I am running the svn copy as of 7-days old.
> I can provide details of memory usage using exmap if required or do some
> testing if required.
>
> - dBera

Yes, please give us an valgrind backtrace. There is a command line to use at
end of HACKING file from svn. Thanks in advance

Gilles Caulier
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[D Bera]

Some more figures,

After startup                                              : 59m  35m  23m
Double click open a jpeg (~ 1.3 MB size)    : 105m  74m  23m
Do nothing in the iamge editor, and close it: 113m  74m  23m

Looks like a leak to me :-(
But again, subsequently opening and closing images dont increase the memory
usage.

- dBera

--
-----------------------------------------------------
Debajyoti Bera @ http://dtecht.blogspot.com
beagle / KDE fan
Mandriva / Inspiron-1100 user
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-2]

Le Lundi 25 Septembre 2006 16:38, Debajyoti Bera a écrit :

> Some more figures,
>
> After startup                                              : 59m  35m  23m
> Double click open a jpeg (~ 1.3 MB size)    : 105m  74m  23m
> Do nothing in the iamge editor, and close it: 113m  74m  23m
>
> Looks like a leak to me :-(
> But again, subsequently opening and closing images dont increase the memory
> usage.
>
> - dBera

Debajyoti, i need the full valgrind backtrace to locate where is the memory
leak. Please give me the full messages from the console.

Gilles

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Moritz Alexander Esser]

Here is mine... same behaviour here.
I hope you enjoy it :)

Regards,
Moritz

Caulier Gilles wrote:

> Le Lundi 25 Septembre 2006 16:38, Debajyoti Bera a écrit :
>> Some more figures,
>>
>> After startup                                              : 59m  35m  23m
>> Double click open a jpeg (~ 1.3 MB size)    : 105m  74m  23m
>> Do nothing in the iamge editor, and close it: 113m  74m  23m
>>
>> Looks like a leak to me :-(
>> But again, subsequently opening and closing images dont increase the memory
>> usage.
>>
>> - dBera
>
> Debajyoti, i need the full valgrind backtrace to locate where is the memory
> leak. Please give me the full messages from the console.
>
> Gilles
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>
>

==9474== Memcheck, a memory error detector.
==9474== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==9474== Using LibVEX rev 1606, a library for dynamic binary translation.
==9474== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==9474== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
==9474== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==9474== For more details, rerun with: -v
==9474==
==9474== Syscall param write(buf) points to uninitialised byte(s)
==9474==    at 0x584CF43: __write_nocancel (in /lib/libpthread-2.4.so)
==9474==    by 0x576EFEE: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5774905: _XFlushInt (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x57749DA: _XReply (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x575AE42: XInternAtom (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x576EB3A: XSetWMProperties (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5219C4E: QWidget::create(unsigned long, bool, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52DD54D: QWidget::QWidget(QWidget*, char const*, unsigned) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE2437: KApplication::init(bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x4EE6AFE: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==  Address 0x65A870C is 244 bytes inside a block of size 16,384 alloc'd
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x575FB2D: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51E6675: qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7025: qt_init(int*, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FAE2: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==
==9474== Syscall param write(buf) points to uninitialised byte(s)
==9474==    at 0x584CF6B: (within /lib/libpthread-2.4.so)
==9474==    by 0x576EFEE: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5774905: _XFlushInt (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x57749DA: _XReply (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x57562F0: XGetWindowProperty (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x57555F5: XGetWMHints (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x521C12F: QWidget::setIcon(QPixmap const&) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4B99DFE: KMainWindow::setIcon(QPixmap const&) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4EE4487: KApplication::setTopWidget(QWidget*) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x4C0F86B: KMainWindow::initKMainWindow(char const*, int) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4C3E091: KMainWindow::KMainWindow(QWidget*, char const*, unsigned) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x40DDF44: Digikam::DigikamApp::DigikamApp() (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==  Address 0x65A8715 is 253 bytes inside a block of size 16,384 alloc'd
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x575FB2D: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51E6675: qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7025: qt_init(int*, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FAE2: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==
==9474== Syscall param write(buf) points to uninitialised byte(s)
==9474==    at 0x584CF6B: (within /lib/libpthread-2.4.so)
==9474==    by 0x576EFEE: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5774905: _XFlushInt (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5751520: XFlush (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x52170EF: QWidget::setCursor(QCursor const&) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x53C2DAC: QSplitterHandle::setOrientation(Qt::Orientation) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x53C3170: QSplitterHandle::QSplitterHandle(Qt::Orientation, QSplitter*, char const*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x53C4FD6: QSplitter::addWidget(QWidget*, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x53C6936: QSplitter::childEvent(QChildEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52A791B: QObject::event(QEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52DFD8B: QWidget::event(QEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x53C6688: QSplitter::event(QEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==  Address 0x65A86B6 is 158 bytes inside a block of size 16,384 alloc'd
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x575FB2D: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51E6675: qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7025: qt_init(int*, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FAE2: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==
==9474== Syscall param writev(vector[...]) points to uninitialised byte(s)
==9474==    at 0x5AC99D2: do_writev (in /lib/libc-2.4.so)
==9474==    by 0x5AC9A7A: writev (in /lib/libc-2.4.so)
==9474==    by 0x576F40D: _X11TransSocketWritev (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x576F04E: _X11TransWritev (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x577471B: _XSend (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5857A4D: XRenderAddGlyphs (in /usr/lib/libXrender.so.1.3.0)
==9474==    by 0x5C109F5: XftFontLoadGlyphs (in /usr/lib/libXft.so.2.1.2)
==9474==    by 0x5C0CFF2: XftGlyphExtents (in /usr/lib/libXft.so.2.1.2)
==9474==    by 0x521F08E: QFontEngineXft::boundingBox(unsigned short) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x521DA43: QFontEngineXft::minRightBearing() const (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x521D987: QFontEngineXft::minLeftBearing() const (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x526381E: QFontMetrics::minLeftBearing() const (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==  Address 0x65A86AC is 148 bytes inside a block of size 16,384 alloc'd
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x575FB2D: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51E6675: qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7025: qt_init(int*, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FAE2: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==
==9474== Syscall param write(buf) points to uninitialised byte(s)
==9474==    at 0x584CF6B: (within /lib/libpthread-2.4.so)
==9474==    by 0x576EFEE: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5774905: _XFlushInt (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5856A4C: XRenderComposite (in /usr/lib/libXrender.so.1.3.0)
==9474==    by 0x520B3A4: QPainter::drawPixmap(int, int, QPixmap const&, int, int, int, int) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x41449DB: Digikam::FolderItem::paintCell(QPainter*, QColorGroup const&, int, int, int) (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==    by 0x538C1F5: QListView::drawContentsOffset(QPainter*, int, int, int, int, int, int) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x53B7F04: QScrollView::viewportPaintEvent(QPaintEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x53B98CE: QScrollView::eventFilter(QObject*, QEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x5387985: QListView::eventFilter(QObject*, QEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52A7825: QObject::activate_filters(QEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52A788A: QObject::event(QEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==  Address 0x65A8A25 is 1,037 bytes inside a block of size 16,384 alloc'd
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x575FB2D: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51E6675: qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7025: qt_init(int*, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FAE2: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==
==9474== Syscall param write(buf) points to uninitialised byte(s)
==9474==    at 0x584CF6B: (within /lib/libpthread-2.4.so)
==9474==    by 0x583248E: _IceTransWrite (in /usr/lib/libICE.so.6.3.0)
==9474==    by 0x5836AF5: _IceWrite (in /usr/lib/libICE.so.6.3.0)
==9474==    by 0x5836BD1: IceFlush (in /usr/lib/libICE.so.6.3.0)
==9474==    by 0x5823A40: SmcSetProperties (in /usr/lib/libSM.so.6.0.0)
==9474==    by 0x51DA428: (within /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51DA56E: (within /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7229: (within /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7B21: (within /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x582664B: _SmcProcessMessage (in /usr/lib/libSM.so.6.0.0)
==9474==    by 0x583737E: IceProcessMessages (in /usr/lib/libICE.so.6.3.0)
==9474==    by 0x51DAAB3: QSmSocketReceiver::socketActivated(int) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==  Address 0x6E2C074 is 12 bytes inside a block of size 1,024 alloc'd
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x582E6E1: IceOpenConnection (in /usr/lib/libICE.so.6.3.0)
==9474==    by 0x58231DC: SmcOpenConnection (in /usr/lib/libSM.so.6.0.0)
==9474==    by 0x51DF8C1: QSessionManager::QSessionManager(QApplication*, QString&, QString&) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524F4DC: QApplication::initialize(int, char**) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FB0A: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==
==9474== Syscall param write(buf) points to uninitialised byte(s)
==9474==    at 0x584CF6B: (within /lib/libpthread-2.4.so)
==9474==    by 0x576EFEE: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5774905: _XFlushInt (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x574ACB7: XCheckTypedWindowEvent (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51DEEDC: QETWidget::translateConfigEvent(_XEvent const*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E8978: QApplication::x11ProcessEvent(_XEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51F92D0: QEventLoop::processEvents(unsigned) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52604F0: QEventLoop::enterLoop() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52603A5: QEventLoop::exec() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524987E: QApplication::exec() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x804A3E7: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==  Address 0x65A8665 is 77 bytes inside a block of size 16,384 alloc'd
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x575FB2D: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51E6675: qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7025: qt_init(int*, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FAE2: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==
==9474== Syscall param write(buf) points to uninitialised byte(s)
==9474==    at 0x584CF6B: (within /lib/libpthread-2.4.so)
==9474==    by 0x576EFEE: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5774905: _XFlushInt (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5857E9C: XRenderCompositeString8 (in /usr/lib/libXrender.so.1.3.0)
==9474==    by 0x5C129AD: XftGlyphRender (in /usr/lib/libXft.so.2.1.2)
==9474==    by 0x5C0C0B5: XftDrawGlyphs (in /usr/lib/libXft.so.2.1.2)
==9474==    by 0x5224A55: QFontEngineXft::draw(QPainter*, int, int, QTextEngine const*, QScriptItem const*, int) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x520A24A: QPainter::drawTextItem(int, int, QTextItem const&, int) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52B11B2: qt_format_text(QFont const&, QRect const&, int, QString const&, int, QRect*, int, int*, int, QTextParag**, QPainter*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52B1525: QPainter::drawText(QRect const&, int, QString const&, int, QRect*, QTextParag**) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x40FA78A: Digikam::AlbumIconItem::paintItem() (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==    by 0x40D04F9: Digikam::IconView::viewportPaintEvent(QPaintEvent*) (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==  Address 0x65A8C29 is 1,553 bytes inside a block of size 16,384 alloc'd
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x575FB2D: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51E6675: qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7025: qt_init(int*, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FAE2: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==
==9474== Syscall param write(buf) points to uninitialised byte(s)
==9474==    at 0x584CF6B: (within /lib/libpthread-2.4.so)
==9474==    by 0x576EFEE: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5774905: _XFlushInt (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x577585B: _XEventsQueued (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5761582: XPending (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51F927B: QEventLoop::processEvents(unsigned) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52604F0: QEventLoop::enterLoop() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52603A5: QEventLoop::exec() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524987E: QApplication::exec() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x804A3E7: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==  Address 0x65A8626 is 14 bytes inside a block of size 16,384 alloc'd
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x575FB2D: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51E6675: qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7025: qt_init(int*, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FAE2: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==
==9474== Syscall param write(buf) points to uninitialised byte(s)
==9474==    at 0x584CF6B: (within /lib/libpthread-2.4.so)
==9474==    by 0x576EFEE: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5774905: _XFlushInt (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x574A87D: XCheckIfEvent (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51DE2D2: QETWidget::translatePaintEvent(_XEvent const*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E9227: QApplication::x11ProcessEvent(_XEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51F92D0: QEventLoop::processEvents(unsigned) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52604F0: QEventLoop::enterLoop() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52603A5: QEventLoop::exec() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524987E: QApplication::exec() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x804A3E7: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==  Address 0x65A87C1 is 425 bytes inside a block of size 16,384 alloc'd
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x575FB2D: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51E6675: qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7025: qt_init(int*, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FAE2: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
TIFFReadDirectory: Warning, /home/moritz/Bilder/Privat/Passbild.tif: unknown field with tag 37724 (0x935c) encountered.
==9474==
==9474== Invalid free() / delete / delete[]
==9474==    at 0x4020F9E: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x5B098ED: free_mem (in /lib/libc-2.4.so)
==9474==    by 0x5B094E1: __libc_freeres (in /lib/libc-2.4.so)
==9474==    by 0x401D23A: _vgnU_freeres (in /usr/lib/valgrind/x86-linux/vgpreload_core.so)
==9474==    by 0x5A9F7D3: _Exit (in /lib/libc-2.4.so)
==9474==    by 0x5A2A80F: (below main) (in /lib/libc-2.4.so)
==9474==  Address 0x59E4BF8 is not stack'd, malloc'd or (recently) free'd
==9474==
==9474== ERROR SUMMARY: 176 errors from 11 contexts (suppressed: 217 from 1)
==9474== malloc/free: in use at exit: 1,348,612 bytes in 3,843 blocks.
==9474== malloc/free: 2,484,194 allocs, 2,480,352 frees, 621,065,947 bytes allocated.
==9474== For counts of detected errors, rerun with: -v
==9474== searching for pointers to 3,843 not-freed blocks.
==9474== checked 3,599,508 bytes.
==9474==
==9474==
==9474== 4 bytes in 1 blocks are definitely lost in loss record 24 of 316
==9474==    at 0x4021384: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x4007019: _dl_map_object_from_fd (in /lib/ld-2.4.so)
==9474==    by 0x4007F20: _dl_map_object (in /lib/ld-2.4.so)
==9474==    by 0x400BA95: openaux (in /lib/ld-2.4.so)
==9474==    by 0x400D271: _dl_catch_error (in /lib/ld-2.4.so)
==9474==    by 0x400BC8C: _dl_map_object_deps (in /lib/ld-2.4.so)
==9474==    by 0x401112E: dl_open_worker (in /lib/ld-2.4.so)
==9474==    by 0x400D271: _dl_catch_error (in /lib/ld-2.4.so)
==9474==    by 0x4010C08: _dl_open (in /lib/ld-2.4.so)
==9474==    by 0x4FB1E1C: dlopen_doit (in /lib/libdl-2.4.so)
==9474==    by 0x400D271: _dl_catch_error (in /lib/ld-2.4.so)
==9474==    by 0x4FB22BB: _dlerror_run (in /lib/libdl-2.4.so)
==9474==
==9474==
==9474== 4,536 (12 direct, 4,524 indirect) bytes in 1 blocks are definitely lost in loss record 116 of 316
==9474==    at 0x4021B49: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x554EB8C: QGList::append(void*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x554ECD0: QGList::insertAt(unsigned, void*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x53A4855: QMenuData::insertAny(QString const*, QPixmap const*, QPopupMenu*, QIconSet const*, int, int, QWidget*, QCustomMenuItem*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x53A4B90: QMenuData::insertSeparator(int) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4C3C8E5: KXMLGUIBuilder::createCustomElement(QWidget*, int, QDomElement const&) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4BDC0CF: KXMLGUI::BuildHelper::processCustomElement(QDomElement const&, int) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4C3E7BB: KXMLGUI::BuildHelper::processActionOrCustomElement(QDomElement const&, bool) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4CA9D1C: KXMLGUI::BuildHelper::processElement(QDomElement const&) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4CA9FB2: KXMLGUI::BuildHelper::build(QDomElement const&) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4CAA0BE: KXMLGUI::BuildHelper::processContainerElement(QDomElement const&, QString const&, QString const&) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4CA9ECE: KXMLGUI::BuildHelper::processElement(QDomElement const&) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==
==9474==
==9474== 1,341 (56 direct, 1,285 indirect) bytes in 1 blocks are definitely lost in loss record 227 of 316
==9474==    at 0x4021B49: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x52DA35B: QWidget::createExtra() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52DCE20: QWidget::createTLExtra() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52DCED7: QWidget::focusData(bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52DDA77: QWidget::QWidget(QWidget*, char const*, unsigned) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x5357B32: QFrame::QFrame(QWidget*, char const*, unsigned) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x53A6605: QPopupMenu::QPopupMenu(QWidget*, char const*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4BE938C: KPopupMenu::KPopupMenu(QWidget*, char const*) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4C7B3B9: KXMLGUIBuilder::createContainer(QWidget*, int, QDomElement const&, int&) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4B7511A: KXMLGUI::BuildHelper::createContainer(QWidget*, int, QDomElement const&, int&, KXMLGUIBuilder**) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4CAA201: KXMLGUI::BuildHelper::processContainerElement(QDomElement const&, QString const&, QString const&) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==    by 0x4CA9ECE: KXMLGUI::BuildHelper::processElement(QDomElement const&) (in /opt/kde/lib/libkdeui.so.4.2.0)
==9474==
==9474==
==9474== 216 bytes in 1 blocks are definitely lost in loss record 253 of 316
==9474==    at 0x4021384: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x57A0BD5: _XimOpenIM (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x57A0A1F: _XimRegisterIMInstantiateCallback (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x5780A77: XRegisterIMInstantiateCallback (in /usr/lib/libX11.so.6.2.0)
==9474==    by 0x51E6A28: qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x51E7025: qt_init(int*, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FAE2: QApplication::construct(int&, char**, QApplication::Type) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x524FE0A: QApplication::QApplication(int&, char**, bool) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x4EE693D: KApplication::KApplication(bool, bool) (in /opt/kde/lib/libkdecore.so.4.2.0)
==9474==    by 0x8049F81: (within /opt/kde/bin/digikam)
==9474==    by 0x5A2A807: (below main) (in /lib/libc-2.4.so)
==9474==
==9474==
==9474== 256 (108 direct, 148 indirect) bytes in 1 blocks are definitely lost in loss record 256 of 316
==9474==    at 0x4021B49: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x421B9C2: Digikam::ManagedLoadSaveThread::createLoadingTask(Digikam::LoadingDescription const&, bool, Digikam::ManagedLoadSaveThread::LoadingMode, Digikam::LoadSaveThread::AccessMode) (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==    by 0x421C8E6: Digikam::ManagedLoadSaveThread::load(Digikam::LoadingDescription, Digikam::ManagedLoadSaveThread::LoadingMode, Digikam::ManagedLoadSaveThread::LoadingPolicy, Digikam::LoadSaveThread::AccessMode) (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==    by 0x421D169: Digikam::SharedLoadSaveThread::load(Digikam::LoadingDescription, Digikam::LoadSaveThread::AccessMode, Digikam::ManagedLoadSaveThread::LoadingPolicy) (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==    by 0x4260FF7: Digikam::DImgInterface::load(QString const&, Digikam::IOFileSettingsContainer*, QWidget*) (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==    by 0x426C5E9: Digikam::Canvas::load(QString const&, Digikam::IOFileSettingsContainer*) (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==    by 0x42C0B7C: Digikam::ImageWindow::slotLoadCurrent() (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==    by 0x42C3D16: Digikam::ImageWindow::qt_invoke(int, QUObject*) (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==    by 0x52A7F18: QObject::activate_signal(QConnectionList*, QUObject*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x55CE60D: QSignal::signal(QVariant const&) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52C3C84: QSignal::activate() (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==    by 0x52CAF72: QSingleShotTimer::event(QEvent*) (in /opt/qt/lib/libqt-mt.so.3.3.6)
==9474==
==9474==
==9474== 304 bytes in 2 blocks are definitely lost in loss record 261 of 316
==9474==    at 0x40206C3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9474==    by 0x40102D8: allocate_dtv (in /lib/ld-2.4.so)
==9474==    by 0x401039B: _dl_allocate_tls (in /lib/ld-2.4.so)
==9474==    by 0x58479DF: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.4.so)
==9474==    by 0x436C5EF: findLockInfo (in /usr/lib/libsqlite3.so.0.8.6)
==9474==    by 0x436D03B: sqlite3UnixOpenReadWrite (in /usr/lib/libsqlite3.so.0.8.6)
==9474==    by 0x4371385: sqlite3pager_open (in /usr/lib/libsqlite3.so.0.8.6)
==9474==    by 0x4358DAE: sqlite3BtreeOpen (in /usr/lib/libsqlite3.so.0.8.6)
==9474==    by 0x436B0FF: sqlite3BtreeFactory (in /usr/lib/libsqlite3.so.0.8.6)
==9474==    by 0x436BA4E: openDatabase (in /usr/lib/libsqlite3.so.0.8.6)
==9474==    by 0x40C85BB: Digikam::AlbumDB::setDBPath(QString const&) (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==    by 0x40B6C35: Digikam::AlbumManager::setLibraryPath(QString const&) (in /opt/kde/lib/libdigikam.so.0.0.0)
==9474==
==9474== LEAK SUMMARY:
==9474==    definitely lost: 700 bytes in 7 blocks.
==9474==    indirectly lost: 5,957 bytes in 155 blocks.
==9474==      possibly lost: 0 bytes in 0 blocks.
==9474==    still reachable: 1,341,955 bytes in 3,681 blocks.
==9474==         suppressed: 0 bytes in 0 blocks.
==9474== Reachable blocks (those to which a pointer was found) are not shown.
==9474== To see them, rerun with: --show-reachable=yes

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

Hi,

here are some numbers of current svn.

First using exmap (which is, according to Lubos Lunak's blog, the tool to be
used to measure memory usage)

Pixmaps are stored in the X server, so the memory usage of X is given as well.
First number is "Effective resident" which is - as there was no swapping -
the effective memory usage in KB.
It is made up of executable code (which can be reduced by stripping) and two
other numbers, "heap" and "anon", no definition from me, both are given here.

Before start
        X 17929 heap 13644 anon 1427

digikam first
        X 23537 heap 13644 anon 6051
        digikam 31574 heap 7152 anon 3228

digikam thumbnail cache
        X 27153 heap 17260 anon 6051
        digikam 31556 heap 7164 anon 3228
(-> 100 pixmaps stored in the server)

digikam image editor one image
        X 34525 heap 18992 anon 11687
        digikam 71146 heap 9096 anon 40592
(-> widget, canvas and image data of one image, pixmaps)

digikam image editor cache full
        X no significant change
        digikam 120500 heap 9220 anon 89764
(-> 40MB DImg cache)

digikam image editor closed (cache still full)
        X no significant change
        digikam 108336, heap 9240 anon 77472

digikam closed
        X 21900 heap 17616 anon 431


Second, using valgrind's massif tool.

The attached chart was taken with a similar run as above.
Colors #1 and #2 represent memory used by DImg.
With the exception of the 45MB peak of "other", the cause of which I don't
know, and QImage::create, which is probably the preview feature, what you can
see from this is that the real large part of memory is used for image
editing.

Marcel

>
> - dBera

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[D Bera]

On 9/27/06, Marcel Wiesweg <[hidden email]> wrote:
> Hi,
>
> here are some numbers of current svn.

Sorry, I couldnt get back earlier. Recently I synced to svn and after
trying to show off some pictures to friends, I got extremely
frustrated. Unlike 0.8.x series, 0.9.x series is not that snappy and
lightweight. Specially when you double click a thumbnail to see an
image. As I am writing this email, I am rebuilding digikam with -g and
then intend to run valgrind on that.
Read my response inline below.

> First using exmap (which is, according to Lubos Lunak's blog, the tool to be
> used to measure memory usage)
>
> Pixmaps are stored in the X server, so the memory usage of X is given as well.
> First number is "Effective resident" which is - as there was no swapping -
> the effective memory usage in KB.
> It is made up of executable code (which can be reduced by stripping) and two
> other numbers, "heap" and "anon", no definition from me, both are given here.
>
> Before start
>         X 17929 heap 13644 anon 1427
>
> digikam first
>         X 23537 heap 13644 anon 6051
>         digikam 31574 heap 7152 anon 3228
>
> digikam thumbnail cache
>         X 27153 heap 17260 anon 6051
>         digikam 31556 heap 7164 anon 3228
> (-> 100 pixmaps stored in the server)
>
> digikam image editor one image
>         X 34525 heap 18992 anon 11687
>         digikam 71146 heap 9096 anon 40592
> (-> widget, canvas and image data of one image, pixmaps)
>
> digikam image editor cache full
>         X no significant change
>         digikam 120500 heap 9220 anon 89764
> (-> 40MB DImg cache)
>
> digikam image editor closed (cache still full)
>         X no significant change
>         digikam 108336, heap 9240 anon 77472
>
> digikam closed
>         X 21900 heap 17616 anon 431

"cache still full"  - which cache is this ? DImg ?
Why is the dimg cache not cleared when the editor is closed ? Is that
for performance reason ? As a result, if I keep open digikam after
viewing a few images, it will keep blocking that 40MB memory ?
I guess what I am asking is why isnt the memory usage after
image-editor same as that before ? I might be ok when I am using
image-editor since I understand it has to do lots of things, but when
I close it, things should be back to normal. (BTW, the image-editor
felt much snappy in 0.8.x series, dunno what changed).

> Second, using valgrind's massif tool.
>
> The attached chart was taken with a similar run as above.
> Colors #1 and #2 represent memory used by DImg.
> With the exception of the 45MB peak of "other", the cause of which I don't
> know, and QImage::create, which is probably the preview feature, what you can
> see from this is that the real large part of memory is used for image
> editing.

I am sorry I didnt quite understand the conclusion :(. Are you saying
that the memory usage is normal(read: as expected) or agreeing that
there is a leak worth investigating?
Thanks,
- dBera

--
-----------------------------------------------------
Debajyoti Bera @ http://dtecht.blogspot.com
beagle / KDE fan
Mandriva / Inspiron-1100 user
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[D Bera]

> > Before start
> >         X 17929 heap 13644 anon 1427
> >
> > digikam first
> >         X 23537 heap 13644 anon 6051
> >         digikam 31574 heap 7152 anon 3228
> >
> > digikam thumbnail cache
> >         X 27153 heap 17260 anon 6051
> >         digikam 31556 heap 7164 anon 3228
> > (-> 100 pixmaps stored in the server)
> >
> > digikam image editor one image
> >         X 34525 heap 18992 anon 11687
> >         digikam 71146 heap 9096 anon 40592
> > (-> widget, canvas and image data of one image, pixmaps)
> >
> > digikam image editor cache full
> >         X no significant change
> >         digikam 120500 heap 9220 anon 89764
> > (-> 40MB DImg cache)
> >
> > digikam image editor closed (cache still full)
> >         X no significant change
> >         digikam 108336, heap 9240 anon 77472
> >
> > digikam closed
> >         X 21900 heap 17616 anon 431

For testing, I changed utilities/imageeditor/editorwindow.cpp:

- EditorWindow::EditorWindow(const char *name)
-           : KMainWindow(0, name, WType_TopLevel)
+ EditorWindow::EditorWindow(const char *name)
+           : KMainWindow(0, name, WType_TopLevel | WDestructiveClose)

which showed substantial reduction in memory when editor window is
closed without any perceivable slowness in reopening the editor window
(I opened/closed the editor window a number of times on different
pictures). Is the hiding of the editorwindow instead of deleting it
_intentional_ ?

Thanks,
- dBera

--
-----------------------------------------------------
Debajyoti Bera @ http://dtecht.blogspot.com
beagle / KDE fan
Mandriva / Inspiron-1100 user
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> "cache still full"  - which cache is this ? DImg ?
> Why is the dimg cache not cleared when the editor is closed ? Is that
> for performance reason ? As a result, if I keep open digikam after
> viewing a few images, it will keep blocking that 40MB memory ?

Yes. I was not involved at the time, but I was told that the old image editor
used the same amount of cache.

> I guess what I am asking is why isnt the memory usage after
> image-editor same as that before ? I might be ok when I am using
> image-editor since I understand it has to do lots of things, but when
> I close it, things should be back to normal. (BTW, the image-editor
> felt much snappy in 0.8.x series, dunno what changed).

The cache is only for opening the image, and shared by the histogram loader
and the image editor. Closing the image editor does not mean you wont open it
again.

Snappiness is very subjective. What has changed? Almost everything.

>
> > Second, using valgrind's massif tool.
> >
> > The attached chart was taken with a similar run as above.
> > Colors #1 and #2 represent memory used by DImg.
> > With the exception of the 45MB peak of "other", the cause of which I
> > don't know, and QImage::create, which is probably the preview feature,
> > what you can see from this is that the real large part of memory is used
> > for image editing.
>
> I am sorry I didnt quite understand the conclusion :(. Are you saying
> that the memory usage is normal(read: as expected) or agreeing that
> there is a leak worth investigating?

I did not find any leak. I won't investigate the heap usage below 10MB. As to
optimizing, it's pretty clear where the large part of the memory is used. And
with out decision to store the image as a "blob" in memory, that's it.
If you want to edit really large images, really larger than any photos taken
with a digital camera, you need memory anyway, and Photoshop.

> Thanks,
> - dBera
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[D Bera]

> > I guess what I am asking is why isnt the memory usage after
> > image-editor same as that before ? I might be ok when I am using
> > image-editor since I understand it has to do lots of things, but when
> > I close it, things should be back to normal. (BTW, the image-editor
> > felt much snappy in 0.8.x series, dunno what changed).
>
> The cache is only for opening the image, and shared by the histogram loader
> and the image editor. Closing the image editor does not mean you wont open it
> again.

While its true that closing it doesnt mean it wont be opened again,
but keeping the whole imageeditor in memory in anticipation that it
will be opened again doesnt sound that right. The situation is
different than photoshop which is only used for image-editing. But
digikam is also used for image viewing/browsing pictures. If I decide
to crop some image while browsing my images, currently the imageeditor
stays in memory even after I am done with cropping. That seems unfair.
I point out in my other post in this thread that creating editorwindow
with flag WDestructiveClose actually removes the window when closing
it and I didnt find any perceptible difference when editorwindow was
invoked again. I am sure there is a good reason for not deleting
imageeditor when it is closed, just that I dont see it.

> Snappiness is very subjective.

:) yes. I meant in 0.8.x series, when I double clicked an image, I
very quickly got this imageeditor window (or whatever it was called)
and I can see the images full-screen there. Now when I want to see a
picture full-screen there is no option other than double-clicking the
image - which does this whole complicated thing thinking I want to
edit the image. I mention in a later post to the list that while
imageeditor is taking about 5-10 times more time to load the same
jpeg. In effect, I want to see a picture full screen, I double click,
wait for 4-5 seconds for the picture to load and this continues even
when I press next/previous. Thats what I see different from 0.8.x
series.

> > I am sorry I didnt quite understand the conclusion :(. Are you saying
> > that the memory usage is normal(read: as expected) or agreeing that
> > there is a leak worth investigating?
>
> I did not find any leak. I won't investigate the heap usage below 10MB. As to
> optimizing, it's pretty clear where the large part of the memory is used. And
> with out decision to store the image as a "blob" in memory, that's it.
> If you want to edit really large images, really larger than any photos taken
> with a digital camera, you need memory anyway, and Photoshop.

I did some more experiments and I didnt find any leak. Except things
were using too much memory. And it could be due the pixmap. Sounds
fair.

Thanks for clarifying,
- dBera

--
-----------------------------------------------------
Debajyoti Bera @ http://dtecht.blogspot.com
beagle / KDE fan
Mandriva / Inspiron-1100 user
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Birkir A. Barkarson]

  > :) yes. I meant in 0.8.x series, when I double clicked an image, I

> very quickly got this imageeditor window (or whatever it was called)
> and I can see the images full-screen there. Now when I want to see a
> picture full-screen there is no option other than double-clicking the
> image - which does this whole complicated thing thinking I want to
> edit the image. I mention in a later post to the list that while
> imageeditor is taking about 5-10 times more time to load the same
> jpeg. In effect, I want to see a picture full screen, I double click,
> wait for 4-5 seconds for the picture to load and this continues even
> when I press next/previous. Thats what I see different from 0.8.x
> series.

I feel, and I think many users do, that double clicking should bring up
a full screen view instead of the editor.  Most of the time I want to
view full screen and step through images (using scroll, page up/down
etc).  When I want to edit I can usually click the edit button but as in
the above I find myself opening the image editor far more often than I
intend to.  This is a bit counter-intuitive and it might be prudent to
alter this behavior.

There seem to be error cropping up in the svn version... yesterday I
couldn't assign thumbnails to albums via the right-click menu.

BAB
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

> I feel, and I think many users do, that double clicking should bring up
> a full screen view instead of the editor.

Amen!

This would save me a lot o f time. Maybe a configurable option would be best
though. That way both modes of operation would be supported.

Dennis
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Colin Guthrie-6]

Dennis Meulensteen wrote:
>> I feel, and I think many users do, that double clicking should bring up
>> a full screen view instead of the editor.
>
> Amen!
>
> This would save me a lot o f time. Maybe a configurable option would be best
> though. That way both modes of operation would be supported.

Yes I too would prefer this.

I very rarely use the editor but quite often want to have a nice viewer...

Perhaps direct entry into the Kipi-Slideshow on pause, with funky OpenGL
overlays for forward/back with fadeing controls and all sorts :)

(sorry been o/d'ing on eye candy of late...)

Col

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Thorsten Schnebeck-2]

Am Dienstag, 17. Oktober 2006 14:35 schrieb Colin Guthrie:
> Dennis Meulensteen wrote:
> >> I feel, and I think many users do, that double clicking should bring up
> >> a full screen view instead of the editor.

and I start crying if a program should use on a double click action when KDE
is configured as single click system ;-)

Bye

  Thorsten

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Markus Spring]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Colin Guthrie schrieb:
> Dennis Meulensteen wrote:
>>> I feel, and I think many users do, that double clicking should bring up
>>> a full screen view instead of the editor.
...
>> This would save me a lot o f time. Maybe a configurable option would be best
>> though. That way both modes of operation would be supported.
...
> I very rarely use the editor but quite often want to have a nice viewer...
Same with me. And as christmas is near, I would like to add a 100% mode in the
viewer to the wish list (you know, sharpness is crucial...)

Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFNNNlxxUzQSse11ARAu/mAJ4zIvibhxDdEtPDXFgqO+q48DXTlwCeIst3
CDcM2GuELOR/lY+3cDjEbng=
=9K6+
-----END PGP SIGNATURE-----
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[D Bera]

> >>> I feel, and I think many users do, that double clicking should bring up
> >>> a full screen view instead of the editor.
> >> This would save me a lot o f time. Maybe a configurable option would be
> >> best though. That way both modes of operation would be supported
> > I very rarely use the editor but quite often want to have a nice
> > viewer...
> Same with me. And as christmas is near, I would like to add a 100% mode in
> the viewer to the wish list (you know, sharpness is crucial...)

For same purpose I filed this a few days ago,
http://bugs.kde.org/show_bug.cgi?id=135655

How should digikam be perceived ?
- Picassa which can also do Photoshop ? (target audience is a viewer who
sometime wants to touch-up their pics)
- or Photoshop with a picassa mode ? (target audience is a pro-photographer
who spends time editing his pictures)

clicking (dbl/single) should act accordingly. IMO, since editing is less freq
used by most current users, it should be an explicit menu item instead of the
default. But then again, its for Gilles and his team to decide :)

- dBera
--
-----------------------------------------------------
Debajyoti Bera @ http://dtecht.blogspot.com
beagle / KDE fan
Mandriva / Inspiron-1100 user
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-2]

On Tuesday 17 October 2006 15:19, Debajyoti Bera wrote:

> > >>> I feel, and I think many users do, that double clicking should bring
> > >>> up a full screen view instead of the editor.
> > >>
> > >> This would save me a lot o f time. Maybe a configurable option would
> > >> be best though. That way both modes of operation would be supported
> > >
> > > I very rarely use the editor but quite often want to have a nice
> > > viewer...
> >
> > Same with me. And as christmas is near, I would like to add a 100% mode
> > in the viewer to the wish list (you know, sharpness is crucial...)
>
> For same purpose I filed this a few days ago,
> http://bugs.kde.org/show_bug.cgi?id=135655
>
> How should digikam be perceived ?
> - Picassa which can also do Photoshop ? (target audience is a viewer who
> sometime wants to touch-up their pics)
> - or Photoshop with a picassa mode ? (target audience is a pro-photographer
> who spends time editing his pictures)
>
> clicking (dbl/single) should act accordingly. IMO, since editing is less
> freq used by most current users, it should be an explicit menu item instead
> of the default. But then again, its for Gilles and his team to decide :)

The team will decide of course.

I'm only read comments from this thread at this moment (:=))...

Gilles
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> How should digikam be perceived ?
> - Picassa which can also do Photoshop ? (target audience is a viewer who
> sometime wants to touch-up their pics)

My personal opinion on the question of our philosophy:
We dont want to do Photoshop. We want to do editing with effects which are
easy to use (direct preview, an image plugin provides a set of actions which
you could do manually in a full-blown image editor, but if you don't want to
know how, you can use the effect easily, with no learning)

> - or Photoshop with a picassa mode ? (target audience is a pro-photographer
> who spends time editing his pictures)

I'd say, we do image management as good as possible, and editing as good and
easy as possible within our limits / market niche.

>
> clicking (dbl/single) should act accordingly. IMO, since editing is less
> freq used by most current users, it should be an explicit menu item instead
> of the default. But then again, its for Gilles and his team to decide :)

It's difficult to decide.
Digikam currently has no dedicated viewer. It has an editor, and it has a
preview function. The image editor acts as a viewer (it does this as long as
I know digikam). It loads slowly (especially RAW), but provides zoom and full
quality
The preview depends on the quality of the embedded thumbnail, and is limited
in detail for some formats (digikam embeds 800x600 previews in some formats it
can save)

Marcel

>
> - dBera
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> For testing, I changed utilities/imageeditor/editorwindow.cpp:
>
> - EditorWindow::EditorWindow(const char *name)
> -           : KMainWindow(0, name, WType_TopLevel)
> + EditorWindow::EditorWindow(const char *name)
> +           : KMainWindow(0, name, WType_TopLevel | WDestructiveClose)
>
> which showed substantial reduction in memory when editor window is
> closed without any perceivable slowness in reopening the editor window
> (I opened/closed the editor window a number of times on different
> pictures). Is the hiding of the editorwindow instead of deleting it
> _intentional_ ?

Yes, the hiding is intentional, to speed things up.
You probably mean the memory used by X.org? That slipped my attention so far.
I need to investigate this.

Marcel

>
> Thanks,
> - dBera
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Dnia wtorek, 17 października 2006 14:35, Colin Guthrie napisał:

> Dennis Meulensteen wrote:
> >> I feel, and I think many users do, that double clicking should bring
> >> up a full screen view instead of the editor.
> >
> > Amen!
> >
> > This would save me a lot o f time. Maybe a configurable option would
> > be best though. That way both modes of operation would be supported.
>
> Yes I too would prefer this.
>
> I very rarely use the editor but quite often want to have a nice
> viewer...

OTOH I use editor very often but I agree that Digikam lacks good viewer.

> Perhaps direct entry into the Kipi-Slideshow on pause, with funky OpenGL
> overlays for forward/back with fadeing controls and all sorts :)
>
> (sorry been o/d'ing on eye candy of late...)

That would be really nice - eye-candy in some aspects is Good Thing(tm)
and this is one of the places where it could excel.

Simpler thing would be to borrow look'n'feel from KPDF (and in future
Okular) presentation mode.

m.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users