[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