[KimDaBa] Re: WARNING about current CVS - STABLE again
Robert L Krawitz
rlk at alum.mit.edu
Fri Jan 14 01:41:10 GMT 2005
From: "Jesper K. Pedersen" <blackie at blackie.dk>
Date: Thu, 13 Jan 2005 20:46:37 +0100
On Thursday 13 January 2005 20:29, Jesper K. Pedersen wrote:
| In qt a thread is allowed to lock a mutex several times, as long as it
| unlocks it the same amount of times.
| In your description below it sounds like it is the GUI thread that simply
| tries to lock twice, and this should therefore not be a problem.
|
| Are you sure that it really lucks up, and not just are slow? Please retry
| without your patch, and give it time.
Ahh, The problem was of course that pixmapLoaded in
thumbnailbuilder called recursively to start another load, which
gave a deadlock. So of course pixmapLoaded should not be called
which protected by a mutex.
So I tried playing around with it. Here are my observations:
1) If I scroll down by holding down the page down key, it still
doesn't refresh for 5-10 seconds when I reach the bottom of the
page (the disk is active all the time, so it's loading thumbnails).
The virtual memory consumption jumps up, but doesn't go all the way
back down. I believe there may be a memory leak because if I
repeatedly scroll all the way down and back up the memory
consumption increases about 8 MB each time through (which may or
may not actually represent a leak). It also appears that there are
some paths in the image manager where the ImageRequest isn't
deleted (which would represent a leak).
I tried tracing calls to stillNeeded, and it looked like a lot of
those calls were succeeding even though I was still scrolling down
the page.
2) Loading large images (by clicking on them) feels like it may be
slower than before. If I load a ~5000x3000 image, the virtual
memory consumption (from top) jumps from about 90 MB to 170 MB,
then jumps again to 240 MB, then back down to 170 MB. When I
dismiss the image (with <escape>), the consumption drops back to 90
MB or so.
Looking at the code, it looks like the QImage isn't always passed
by reference (it's sometimes passed by copy). In particular, the
ImageRequest stores it as a deep copy. This would be a worthwhile
optimization, I think.
3) If I change the size of the thumbnails, the row spacing, etc. while
the thumbnail view is open, it starts chewing up virtual memory
like there's no tomorrow (my suspicion is that it immediately tries
to reload every image in the thumbnail view). I think this also
happened when I tried to do build all thumbnails with the thumbnail
view open, but I'm less certain.
4) When I start the CVS version, I get a warning that some images
don't have a width or height, and to remedy that by doing delete
thumbnails followed by rebuild all thumbnails. Aside from the fact
that this is an extremely expensive operation, it didn't even
resolve the problem; the next time I started it (after saving), I
got the same message.
--
Robert Krawitz <rlk at alum.mit.edu>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
More information about the Kphotoalbum
mailing list